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EXECUTIVE  SUMMARY 
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under  consideration  to  promote  the  reusability  of  JAMPS  software. 

Ada  software  development  tools  (for  the  MC68000)  currently 
exist  in  rudimentary  form,  but  are  not  considered  adequate  for 
duplicating  JAMPS  software  at  this  time.  However,  the  tools  are 
expected  to  improve  sufficiently  that  reimplementaton  in  Ada  might 
reasonably  begin  in  FY85. 
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reasonable  to  reconsider  the  possibility  of  duplicating  JAMPS 
software  in  Ada. 

Once  a  contract  has  been  awarded,  it  will  take  an  estimated  two 
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SECTION  1 
INTRODUCTION 


1.1  BACKGROUND 

JINTACCS  Is  an  acronym  for  the  Joint  Interoperability  Tactical 
Command  and  Control  Systems.  The  JINTACCS  Automated  Message 
Processing  System,  JAMPS,  'Is  a  portable  set  of  computer-controlled 
equipment  for  assisting  a  group  of  collocated  operators  in  composing 
and  exchanging  JINTACCS  messages.  It  provides  each  operator  with  a 
work  station  for  composing  messages  and  interface  equipment  for 
sending  and  receiving  messages  over  a  long-haul  communications  link, 
as  well  as  for  sending  messages  to  and  receiving  messages  from  other 
operators  in  the  local  group.” 

Prototype  versions  of  JAMPS  have  been  designed  and  built  by  The 
MITRE  Corporation.  JAMPS  has  undergone  compatibility  and  inter¬ 
operability  testing  and  operational  effectiveness  demonstrations 
(OED)  during  military  exercises.  As  a  result  of  these  exercises,  it 
was  decided  that  the  principal  processing  component,  the  DEC  11/23, 
should  be  replaced  with  a  Motorola  MC68000- based  computer  and  a 
faster  disk  to  overcome  response  time  problems  and  generally  improve 
system  performance.  The  JAMPS  software,  written  in  the  "C”  language 
and  executed  under  the  UNIX*  operating  system,  is  being  transported 
to  the  MC68000  at  this  time. 

Approximately  a  dozen  Air  Force  organizations  have  expressed 
interest  in  reusing  JAMPS  software  (but  not  necessarily  the  hard¬ 
ware)  in  other  military  systems.  Inasmuch  as  the  "C”  language  is 
not  approved  for  use  in  DoD  acquisition  programs  and  because  the  use 
of  Ada  will  soon  become  mandatory  in  many  types  of  defense  systems, 
the  Electronic  Systems  Division  of  USAF  has  asked  MITRE  to  investi¬ 
gate  the  feasibility  of  duplicating  JAMPS  software  in  the  Ada 
language.  This  document,  prepared  in  response  to  ESD's  request. 
Includes  estimates  for  the  time,  money,  and  manpower  required  to 
rewrite  JAMPS  software  in  Ada.  It  also  presents  the  advantages  and 
disadvantages  of  undertaking  such  an  effort.  This  Investigation  was 
Jointly  funded  by  Project  4100  (JAMPS)  and  Project  572D  (Ada  transi¬ 
tion  planning  associated  with  the  Computer  Resources  Management 
Program  PE64740F)  and  consequently  is  more  thorough  than  might 
otherwise  be  expected  if  sponsored  by  Project  4100  alone. 


*UNIX  is  a  trademark  of  Bell  Laboratories. 
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1.2  JAHPS  HARDWARE  CONFIGURATION 

There  are  two  types  of  JAMPS  hardware: 

1.  Work  station 

2.  Information  distribution  network 

The  work  station  hardware  to  which  the  JAMPS  system  is  now 
transported  is  for  operational  demonstration  of  the  JAMPS  concept. 

It  will  provide  better  response  time  performance  and  greater  storage 
capacity  than  the  demonstration  hardware  used  in  previous 
operational  tests. 

The  upgraded  work  station  includes  the  following  hardware 
elements: 

o  MC68000  computer,  0.5  Mbyte  main  memory 
o  Display 
o  Keyboard 

o  Storage  Device  (40  or  70  megabyte  Winchester  disk  drive) 
o  Printer 

o  Q-bus  Interface  hardware 
o  DEC  DLVII-E  asynchronous  line  Interface 
o  DEC  DLVII-J  four-part  RS-232  multiplexer 
o  Floppy  disk  drive;  8-lnch,  .1  Mbyte  floppy  disks 
o  Diagnostic  firmware  and  control  panel 
Figures  1  and  2  depict  the  hardware  configuration. 


1.3  FUNDAMENTAL  CONCEPTS  OF  THE  EXISTING  SOFTWARE  ARCHITECTURE  FOR 
JAMPS 

All  valid  JINTACCS  message  types  and  formats  are  under 
configuration  control  by  the  Army.  Information  pertaining  to 
JINTACCS  message  types  and  formats  is  being  supplied  by  the  Army  on 
a  magnetic  tape  (l.e.,  the  "JINTACCS  Tape")  to  the  Data  Processing 
Center  at  Langley  AFB,  Tactical  Air  Command  (TAC).  At  the  center 
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It  Is  reformatted  by  an  off-line  batch  program  on  the  PDP-11/70, 
yielding  another  kind  of  tape,  known  in  the  JAMPS  community  as  "the 
source  tape”  (figure  3).  This  "source  tape”  serves  as  the  primary 
form  of  input  to  JAMPS  off-line  programs.  There  is  concern  that  the 
continued  existence  of  JAMPS  may  be  jeopardised  if  the  Army  were  to 
8 top  producing  JINTACCS  tapes  or  if  the  Langley  Data  Processing 
Center  were  to  discontinue  the  maintenance  of  the  program  which 
reconstructs  the  JINTACCS  data  on  "source  tapes."  The  JAMPS  project 
personnel  would  prefer  to  input  the  JINTACCS  tape  directly, 
bypassing  the  Data  Processing  Center  at  Langley  AFB  altogether. 

Off-line  (IBLD)  programs  in  JAMPS  read  the  "source  tape"  while 
generating  object  data  base  files  for  the  disk  contained  in  each 
work  station.  Other  off-line  JAMPS  software  checks  the  consistency 
and  completeness  of  this  disk-resident  data.  When  it  is  determined 
that  the  disk-resident  files  are  properly  populated,  the  operator  is 
permitted  to  load  and  enable  the  on-line  programs  used  in  real  time 
operations.  The  JAMPS  on-line  software  provides  real  time  display 
and  communication  capabilities.  The  large  disk-resident  files  which 
are  generated  off-line  remain  unchanged  during  on-line  operations. 
Successful  operation  of  the  on-line  functions  depends  on  the 
existence  of  an  error-free  data  base  on  disk.  Error  checking  of  the 
data  in  disk-resident  files  is  not  performed  on-line  because  this 
would  degrade  response- time  performance.  One  of  the  most  signifi¬ 
cant  features  of  JAMPS  is  that  the  off-line  and  on-line  programs 
need  not  be  modified  as  the  result  of  changes  to  JINTACCS  message 
types  and  formats. 

During  the  past  year,  considerable  effort  has  been  expended  to 
measure  computer  resource  utilisation  by  JAMPS  on-line  programs. 

As  the  result  of  these  efforts,  it  has  been  determined  that  the 
responsiveness  of  the  on-line  software  is  being  impaired  because  of 
excessive  disk-access  requests.  To  remedy  this  situation,  MITRE 
personnel  have  proposed  (along  with  other  modifications)  that  the 
disk-file  structures  be  reorganised  in  a  more  efficient  manner. 


1.4  ASSUMPTIONS 

o  Duplicating  JAMPS  software  using  Ada  will  be  accomplished  as 
an  acquisition  effort  by  a  contractor. 

o  The  Ada  software  for  JAMPS  will  be  procured  in  accordance 
with  300-series  regulations.  If  the  normal  ESD  procurement 
practices  (800-series  regulations)  were  followed  instead, 
the  software  development  cost  estimates  shown  herein  should 
be  Increased  rather  substantially,  perhaps  even  doubled. 
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o  The  development  of  software  in  Ada  will  not  be  on  a 
critical-path  schedule  for  JAMPS  because  the  existing 
software  written  in  "C"  will  have  already  been  transported 
to  the  MC68000. 

o  The  requirements  baseline  used  by  the  contractor  will 
include  the  existing  MITRE  documentation  for  JAMPS,  with 
amendments  1)  to  update  the  operator-interface  description, 
2)  to  include  requirements  for  response-time  perforaance  and 
excess  processing  capabilities  (e.g.,  for  future  growth), 
and  3)  to  include  new  requirements  for  a  local  area  network. 

o  The  contractor  will  receive  considerable  support  from  the 
Air  Force  in  interpreting  the  system  requirements. 

o  The  existing  allocation  of  functions  between  hardware  and 
software  in  JAMPS  will  remain  unchanged  during  the 
reimplementation  using  Ada.  Therefore,  only  C  level  (not  A 
or  B  level)  documentation  need  be  prepared  by  the 
contractor. 

o  The  current  hardware  configuration,  including  the  MC68000 
computer,  will  be  the  basis  for  software  development  in  Ada, 
and  the  main  memory  of  the  computer  will  be  increased  to  1- 
megabyte  capacity. 

o  The  off-line  programs  used  by  the  Data  Processing  Center  at 
Langley  AFB  to  process  the  JXNTACCS  tape  will  be  modified  by 
the  government  to  produce  a  new  type  of  "source  tape"  format 
which  substantially  reduces  the  complexity  of  the  off-line 
(IBLD)  programs  in  JAMPS;  it  is  assumed  that  existing  JAMPS 
off-line  functions  which  heavily  utilise  TACC  and  LEX 
functions  will  not  be  duplicated  in  Ada. 

o  Major  emphasis  will  be  given  to  software  reusability  during 
the  reimplementation  in  Ada,  and  this  will  Increase  the 
contractor's  costs  for  software  development  by  20%. 

o  The  TCP/IP  communications  handlers  available  in  the  Berkeley 
UNIX  4.2  (estimated  to  be  6500  lines  of  "C"  source  code)  can 
easily  be  Incorporated  into  either  the  UNIX  or  the  ROS 
operating  systems  used  in  the  two  alternative  Ada  Run  Time 
Environments  available  today  from  Telesoft  Corporation. 

o  The  JAMPS  software  architecture  will  be  fully  redesigned  by 
the  contractor  in  order  to  take  maximum  advantage  of 
desirable  features  inherently  available  in  the  Ada  language. 
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o  The  number  of  source  statements  to  be  developed  in  Ada  can 
be  predicted  accurately  by  applying  conversion  factors, 
based  on  the  results  from  a  recoding  experiment  ,  to 
extrapolate  from  the  actual  sizing  data  for  the  existing 
software  written  in  "C“ . 

o  Programmer  productivity  in  Ada  will  be  moderately  less  than 
that  with  other  higher  order  languages. 

o  As  an  early  user  of  Ada,  the  JAMPS  project  is  liable  to 
attract  widespread  attention  within  ESD;  therefore,  the 
level  of  effort  for  contract  monitoring  support  will  be 
larger  than  normal  for  an  undertaking  of  this  sice. 


1.5  GONCLUSIOlfS 

o  The  current  status  of  Ada  programming  support  environments 
for  the  NCiMM,  including  but  not  limited  to  Ada  compilers, 
is  not  adequate  for  duplicating  JAMPS  software  in  Ada  today. 
However,  the  programming  tools  available  from  one  software 
vendor,  Telesoft,  are  expected  to  improve  sufficiently  over 
the  next  year  so  that  the  use  of  Ada  for  JAMPS  can  be 
undertaken  in  FT85.  The  Ada  programming  support  tools 
currently  offered  by  a  second  software  vendor,  Irvine 
Computer  Sciences  Corporation,  are  judged  to  be  less 
adequate  than  those  of  Telesoft  at  this  tine,  but  will 
be  of  potential  Interest  if  redevelopment  of  JAMPS  software 
in  Ada  begins  late  in  FY85. 

o  The  feasibility  of  using  Ada  to  duplicate  JAMPS  software 
will  be  determined  largely  by  the  characteristics  of  the 
particular  compiler  implementations  (and  Ada  run  time 
environments)  for  the  MC68000;  the  Ada  language  itself  is 
not  the  problem.  Certain  optional  features  need  to  be  added 
to  the  existing  Ada  run  time  environments  in  order  for  any 
of  these  environments  to  be  amenable  for  use  in  the  JAMPS 
application.  The  development  schedules  for  such 
enhancements  are  not  known  precisely,  but  it  is  our 
assessment  that  the  necessary  improvements  will  have  been 
completed  by  FY85. 

o  The  total  cost  to  duplicate  JAMPS  software  in  Ada  is 
estimated  to  be  $4.5M  (1983  dollars).  This  estimate 
Includes  work  to  be  performed  by  a  software  contractor, 
contract  monitoring  support,  software  redesign  by  the  Data 
Processing  Center  at  Langley  AFB,  consulting  services,  and 


the  acquisition  of  appropriate  computing  facilities  and 
programming  aupport  tools  for  Ada  software  development.  An 
upper  bound  for  the  total  cost  for  re implementation  in  Ada, 
baaed  on  varioua  peasiaiatic  assumptions,  is  $6.3M. 

o  The  existing  JAMPS  software  written  in  "C"  will  be  awkward 
to  modify  for  use  in  other  systems  because  the  record 
formats  for  disk  files  are  not  explicitly  defined  (in  "C" 
source  code)  and  are  only  partially  described.  In 
addition,  the  "C"  software  was  not  developed  with  reusa¬ 
bility  in  mind,  and  therefore  machine  dependencies,  compiler 
dependencies,  and  run  time  environment  dependencies  have  not 
been  carefully  isolated  and  encapsulated  in  separate  modules 
with  appropriate  annotations  and  documentation. 

o  The  reliability  of  object  code  generated  by  incomplete 
versions  of  the  compilers  currently  available  for  the 
MC68000  is  fairly  good. 

o  Early  indications  suggest  that  the  response-time  performance 
of  Ado-compiled  programs  in  the  MC68000  will  be  satisfactory 
for  use  in  JAMPS. 

o  A  separate  Ada  software  development  facility  will  be  needed 
for  JAMPS;  the  memory  sice  of  the  JAMPS  MC68000  (and  disk 
unit)  is  not  adequate  for  an  Ada  compiler  which  must  have 
access  to  extensive  software  libraries  (source/ object  code). 

o  Software  development  in  Ada  on  the  MC68000  will  be  Impeded 
by  the  unavailability  of  sultabla  tools  for  configuration 
control  and  performance  measurement,  and  therefore  the  Air 
Force  will  be  obliged  to  develop  its  own  tools  for  these 
purposes . 

o  JAMPS  offers  an  unusually  good  situation  for  early  use  of 
the  Ada  language  because  the  system  already  exists  and  any 
reimplementation  in  Ada  will  not  be  driven  by  the  tight 
development  schedules  which  often  characterize  ESD  procure¬ 
ment  efforts.  The  amount  of  code  to  be  developed  in  Ads  is 
far  less  than  the  average  size  C3I  system.  The  potential 
for  reuse  of  JAMPS  software  in  other  systems  is  unusually 
high. 

o  The  Investment  to  date  in  "C"  language  software  for  JAMPS  is 
very  substantial  (13  man-years  of  MITRE  effort  and  5  man- 
years  of  Air  Force  personnel  tine),  perhaps  3  man-years  of 
which  would  be  recoverable  if  JAMPS  software  were  to  be 
relmplenented  in  Ada. 
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1.6  RECOMMENDATIONS 

o  Do  not  undertake  an  effort  to  duplicate  JAMPS  software  in 
Ada  until  such  tine  as  a  suitable  coapiler  with  an 
appropriate  run  tiae  environaent  is  fully  available  and  has 
been  validated  by  the  Ada  Joint  Prograa  Office.  In 
addition,  other  necessary  Ada  prograaaing  support  tools 
should  also  be  readily  obtainable. 


1.7  SCOPE 

The  reaainder  of  this  report  is  organised  into  four  major 
section*  as  follows: 

o  Feasibility  of  duplicating  JAMPS  software  using  Ada 

o  Estimated  number  of  source  statements  of  Ada  to  be  developed 
for  JAMPS 

o  Manpower,  schedule,  and  cost  estimates 

o  Advantages  and  disadvantages  of  relapleaentlng  JAMPS 
software  in  Ada. 
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SECTION  2 


FEASIBILITY  OF  DUPLICATING  JAMPS  SOFTWARE  IN  ADA 


Issues  surrounding  the  feasibility  of  duplicating  JAMPS 
software  In  Ada  are  presented  in  the  following  order: 

o  Availability  of  Ada  compilers  for  the  MC68000 

o  Availability  of  Ada  programming  support  tools  for  the 
MC68000 

o  Appropriateness  of  existing  Ada  run  time  environments 
o  Predicted  run  time  performance 
o  Compiler  reliability 

o  Physical  limitations  of  Telesoft's  Ada  compilers 


2.1  AVAILABILITY  OF  ADA  COMPILERS  FOR  THE  MC68000 

Telesoft  Corporation^  ]  and  Irvine  Computer  Sciences 
Corporation  (ICSC)[3]  are  the  only  firms  which  have  formally 
announced  the  availability  of  Ada  compilers  for  the  MC68000.  The 
Telesoft  and  ICSC  Ada  compilers  do  not  presently  support  the  full 
Ada  language  and  therefore  are  not  ready  to  be  validated  by  the  Ada 
Joint  Program  Office.  Accordingly,  these  compilers  are  unsuitable 
for  use  in  DoD  acquisition  programs  (per  draft  DoD  Directive 
5000.31 [4]).  However,  both  Telesoft  and  ICSC  claim  that  their 
compilers  will  be  ready  for  validation  in  1984. 

As  will  be  explained  further  on,  Telesoft  has  many  different 
versions  of  the  Ada  compiler  for  the  MC68000  and  not  all  of  them 
appear  to  be  suitable  for  the  JAMPS  application.  The  order  in  which 
the  many  different  versions  of  the  Telesoft  compiler  will  reach 
completion  and  undergo  validation  tests  is  unclear.  It  is  entirely 
possible  that  some  of  the  Telesoft  compiler  versions  will  never  be 
fully  developed  and  therefore  will  never  be  validated.  Finally, 
there  is  only  one  version  of  the  ICSC  Ada  compiler  for  the  MC68000 
and  its  development  schedule  is  also  undetermined. 


2.2  AVAILABILITY  OF  ADA  PROGRAMMING  SUPPORT  TOOLS  FOR  MC68000 


DoD  has  issued  a  oonblnding  set  of  guidelines [  6  ]  for  support 
tools  to  be  used  In  conjunction  with  compilers  for  Ada  software 
development.  In  table  1,  these  DoD  guidelines  are  compared  with  the 
tool  capabilities  offered  by  Telesoft  and  by  ICSC  for  the  MC68000. 
This  information  in  table  1  is  based  upon  sales  brochures  and 
telephone  communications  with  marketing  representatives.  It  appears 
that  the  lack  of  tools  for  configuration  control  and  performance 
analysis  (static  and  dynamic  analyzers)  will  significantly  hinder 
any  attempts  to  duplicate  JAMPS  software  in  Ada.  Such  tools  could 
be  procured  directly  from  a  software  vendor,  but  this  would 
significantly  increase  the  budget  required  for  recoding  of  JAMPS 
software  in  Ada. 


2.3  APPROPRIATENESS  OF  EXISTING  ADA  RUN  TIME  ENVIRONMENTS 

JAMPS  software  can  easily  be  recoded  in  Ada.  Nevertheless, 
recoding  in  Ada  may  not  be  a  practical  course  of  action.  The 
appropriateness  of  the  existing  Ada  run  time  environments,  more  than 
anything  else,  will  determine  the  feasibility  of  duplicating  JAMPS 
software  using  Ada.  As  a  programming  language,  Ada  has  eliminated 
many  of  the  fundamental  design  choices  which  traditionally  have  been 
made  by  applications  software  designers.  Although  the  syntax  of  the 
Ada  language  has  been  rigorously  standardized,  many  of  the  features 
of  Ada  run  time  environments  have  been  left  to  the  discretion  of  the 
individual  compiler  designer.  For  this  reason,  the  selection  of  a 
compiler  based  on  an  Inappropriate  run  time  environment  can  kill  a 
project  before  a  single  line  of  applications  code  has  been  written. 
The  question  "can  we  use  Ada"  is  meaningless  because  there  are  many 
degrees  of  freedom  in  the  design  of  Ada  compilers.  It  is  more 
reasonable  to  ask  "can  we  use  a  specific  compiler  (i.e.,  one  of  the 
many  different  Ada  Telesoft  compilers  or  the  ICSC  compiler  targeted 
to  the  MC68000)  for  the  JAMPS  project?” 

The  ensuing  discussion  of  run  time  environments  is  organized  as 
follows: 

o  Definition  of  "Ada  run  time  environment” 

o  Formal  requirements  for  Ada  run  time  environments 

o  Optional  features  for  Ada  run  time  environments 

o  Comparison  between  JAMPS'  needs  versus  capabilities  available 
with  existing  Ada  run  time  environments 


Table  1 


Survey  of  Existing  Ada  Programing  Support  Tools  for  MC68000 


Software  Tool 

Telesoft/LabTek 

Status 

ICSC 

Status 

Text  Editor  (for 
entering  and  modi¬ 
fying  Ada  source  code) 

Available  now  from 
Telesoft 

Available  now 

Pretty  Printer  (for 
printing  text  in  leg¬ 
ible  formats) 

Available  now  from 
LabTek  with  WICAT 
version  of  MC68000 

Unavailable 

Compiler  (for  trans¬ 
lating  Ada  source  code 
into  object  code  for 
execution  on  MC68000) 

Available  in  partial 
form  now;  should  be 
fully  available  in 

1984 

Available  now  in 
partial  form; 
should  be  fully 
available  in  1984 

Linkers  (for  resolving 
Interfaces  between 
separately  compiled 
modules,  forming 
executable  programs) 

Available  now  from 
Telesoft 

Available  now 
from  ICSC 

Loaders  (for  loading 
executable  programs 
in  both  host  and 
target  computers) 

Available  now  from 
Telesoft. 

Available  now 

Symbolic  debugger  (for 
snapshots,  traces,  etc.) 

Under  development  at 
Telesoft;  due  for 
delivery  in  1984. 

Not  available; 
not  in  develop¬ 
ment. 

Static  analyzer  (for 
data  item  set-use 
listings,  cross- 
reference  maps, 
calling  relationships) 

Not  available;  not 
currently  in  develop¬ 
ment. 

Not  available; 
not  in  develop¬ 
ment. 

Dynamic  analysis  tools 
(frequency  analyzer, 
timing  analyzer) 

Generally  not  avail¬ 
able;  LabTek  offers  a 
simple  routine  for 

Not  available; 
not  in  develop¬ 
ment. 

measuring  single-thread 
execution  times. 
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Table  1  (Concluded) 

Survey  of  Existing  Ada  Programing  Support  Tools  for  MC68000 


Software  Tool 


Terminal  Interface 
Routines 

Command  Interpreter 
(accepts  commands 
to  invoke  tools) 

Configuration  Manage¬ 
ment  Tools 


Stub  Generator  (to 
insert  dummy  program 
elements 


Telesoft/LabTek 

Status 


Available  now  from 
Telesoft 

Available  now  from 
Telesoft 


Not  available;  not 
currently  in  develop¬ 
ment 

Not  available;  not 
currently  in  develop¬ 
ment 


ICSC 

Status 


Available  now 


Available  now 


Not  available; 
not  in  develop¬ 
ment 

Not  available; 
not  in  develop¬ 
ment 
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2.3.1  Ada  Run  Time  Environment  Defined 


The  following  material  is  quoted  from  “The  Ada  Run  Time 
Environment,"  a  lecture  given  by  Dr.  Joseph  K.  Cross,  Sperry  UNIVAC, 
at  an  AdaTEC  Meeting,  held  in  Dallas,  Texas,  on  20  October  1983: 

"An  Ada  run  time  environment  Is,  roughly,  the  set  of 
target-machine  facilities  that  an  Ada  compiler  can  use  to  carry  out 
the  run-time  operations  required  by  Ada  programs.  Those  facilities 
consist  of  the  instruction  set  provided  by  the  physical  target 
machine,  possibly  with  additions  and  deletions.  Additions  to  the 
facilities  provided  by  the  physical  target  machine's  Instruction  set 
are  generally  provided  by  some  predefined  software,  such  as  an 
executive,  that  in  the  compiler's  eyes,  might  as  well  be  implemented 
in  hardware.  Other  additions  to  the  physical  target  machine's 
facilities  can  be  provided  by  additional  hardware,  such  as  an  array 
processor,  and  by  user  microcode.  Deletions  from  the  physical 
target  machine's  facilities  generally  result  from  a  conscious 
decision  not  to  use  some  capability,  generally  in  the  Interest  of 
safety  or  simplicity.  For  example,  after  it  had  been  decided  to  use 
a  certain  executive  in  the  target  machine,  it  might  be  determined 
that  all  code  emitted  by  the  Ada  compiler  will  only  run  in  the  task 
state;  then,  the  privileged  instructions  in  the  hardware's 
instruction  set  would  not  be  usable  by  the  Ada  compiler,  and  would 
therefore  not  be  part  of  the  run  time  environment." 

"After  the  target  hardware  has  been  chosen  [i.e.,  the  MC68000], 
after  any  predefined  software  [i.e.,  UNIX  operating  system,  math 
routines,  etc.]  have  been  specified,  and  after  all  restrictions  and 
conventions  have  been  imposed,  the  compiler  sees  as  a  new  target 
machine  the  virtual  target  machine  for  which  all  code  is  actually  to 
be  emitted.  To  the  compiler,  this  virtual  target  machine  is  as 
different  from  the  original  physical  target  as  if  it  were  a 
different  box:  for  example,  the  virtual  box  may  have  a  SINE 
instruction  while  the  physical  machine  did  not,  and  the  physical 
machine  might  let  any  register  be  used  as  a  stack  pointer  while  the 
virtual  machine  reserves  register  15  for  that  purpose." 

2.3.2  Formal  Requirements  for  Ada  Run  Time  Environments 


The  Ada  Language  Reference  Manual [  6]  levies  a  minimal  number 
of  requirements  on  run  time  environments.  These  requirements  are 
summarized  as  follows: 

o  Operations  —  (e.g.,  addition,  comparison,  assignment, 
indexing)  on  various  kinds  of  values  (e.g.,  integer, 
floating  and  fixed  point  Boolean,  record,  array).  Branches 
(GO  TO,  IF,  CASE,  LOOP,  Subprogram  CALL,  and  Return)  are 
also  required. 


o  Tasking  —  (creation/destruction  of  tasks,  activation/ 
abortion/ termination  of  tasks,  execution  (start/stop)  and 
rendezvous  (simultaneous  synchronization  and  data 
interchange)). 

o  Input/Output  —  (sequential,  direct  access,  text,  and 
low-level  I/O) . 

o  Exception  Processing  —  (Ada  requires  that  certain  errors  be 
detected  at  run-time,  such  as  an  attempt  to  assign  the  value 
11  to  a  variable  that  has  been  declared  to  hold  only  values 
between  1  and  10.  Such  a  run-time  error  is  called  an 
exception,  and  the  result  of  an  exception  is  to  transfer 
control  to  a  user-specified  exception  handler). 

o  Memory  Management  —  (ability  to  store  and  retrieve  values). 

2.3.3  Optional  Features  for  Ada  Run  Time  Environments 


This  section  provides  examples  of  the  facilities  that  a 
run  time  environment  may  provide  over  and  above  those  that  are 
required  as  described  in  section  2.3.2.  The  list  is  illustrative 
and  does  not  attempt  to  exhaust  the  full  set  of  possibilities. 

o  Interrupt  Handling.  In  Ada,  an  interrupt  is  treated  like  an 
entry  call  from  an  invisible  task  of  very  high  priority. 
Hence  a  run  time  environment  can  satisfy  the  letter  of  the 
law  by  treating  Interrupts  just  like  any  other  tasking 
operation.  In  some  cases,  JAMPS  might  need  some  form  of 
expedited  dispatching  for  such  things  as  character-echo  at 
the  display  console;  interrupt  handling  tasks  may  be  given 
control  directly  upon  receipt  of  the  interrupt,  and  without 
intervening  enqueuing,  scheduling  decision,  and  dequeuing  of 
a  request.  Also,  advantage  may  be  taken  of  the  hardware 
register-saving  capabilities. 

o  Fancy  Memory  Management.  Use  of  overlays,  nonresident  data, 
and  garbage  collection. 

o  Distributed  Processing  and  Multiprocessing.  The  virtual 
machine  on  which  an  Ada  program  runs  may  have  more  than  one 
processor;  the  Ada  language  definition  leaves  these  issues 
up  to  the  compiler  designer. 

o  Multiprogramming.  Various  processing  priorities  may  be 
assigned  individually  to  Ada  task  programs  and  the  run  time 
environment  may  provide  preemptive  scheduling  capabilities. 
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o  Fancy  I/O.  Asynchronous  I/O,  formatted  I/O,  use  of  key 
words . 

2.3.4  Preliminary  Selection  of  Run-Time  Environments  for  JAMPS 

At  the  outset,  there  are  four  versions  of  the  Telesoft  Ada 
compiler  to  be  considered.  These  four  versions  are  differentiated 
on  the  basis  of  their  respective  run  time  environments  as  follows: 

o  P-code  Interpreter  under  the  UNIX  operating  system 

o  P-code  Interpreter  under  the  ROS  operating  system 

o  Machine  code  executed  under  UNIX  (analogous  to  the  ICSC 
compiler) 

o  Machine  code  executed  under  ROS 

Two  versions  of  the  Telesoft  Ada  compiler  generate  P-code  (a 
Pascal  derivative).  The  front-end  of  the  compiler  generates  P-code 
on  a  host  computer  (VAX,  IBM  370,  or  MC68000)  and  this  intermediate 
form  is  then  downloaded  Into  the  target  computer  (the  MC68000  In 
JAMPS)  where  it  is  interpreted  on-line  by  the  "Run  Time  Kernel" 
(l.e.,  run  time  environment  software).  This  means  that  the  final 
part  of  translation  and  execution  occur  more  or  less  simultaneously. 
For  real-time  applications,  the  use  of  an  Interpreter  in  an  Ada  run 
time  environment  would  be  a  mistake;  the  response-time  performance 
with  an  interpreter  would  be  intolerably  slow. 

Two  more  recent  versions  of  the  Telesoft-Ada  compiler  plus  the 
ICSC  compiler  all  emit  low-level  (machine  language)  outputs.  These 
compilers  convert  Ada  source  code  into  object  programs  in  machine 
language  form  which  can  then  be  downloaded  (from  the  host)  into  the 
target  computer  for  execution  under  the  control  of  an  Ada  run  time 
environment.  This  second  type  of  compiler  is  potentially  of 
Interest  for  use  In  development  of  software  for  JAMPS. 

Telesoft  provides  two  different  run  time  environments  based  on 
the  UNIX  and  the  ROS  operating  systems,  respectively.  Programs 
compiled  via  the  ICSC-Ada  compiler  will  only  execute  under  UNIX. 
Telesoft-UNIX  requires  a  lot  more  memory  (260  Kbytes)  than  ROS  (80 
Kbytes)  in  the  target  computer.  UNIX  is  reputed  to  be  significantly 
slower  and  more  unwieldy  for  real  time  applications  than  ROS. 
Nevertheless,  the  use  of  UNIX  in  other  systems  is  so  widespread  that 
in  the  interest  of  promoting  widespread  reusability  of  JAMPS 
software,  the  run  time  environment  based  on  execution  of  machine 
code  under  UNIX  should  be  seriously  considered. 


2.3.5  Comparison  of  JAMPS  Requirements  Versus  the  Characteristics 
of  Selected  Ada  Run  Time  Environments 

Table  2  shows  a  comparison  between  JAMPS  requirements  versus 
capabilities  available  with  various  Ada  run  time  environments.  It 
is  assumed  that  the  JAMPS  program  will  have  been  compiled  into 
machine  language  format.  It  is  further  assumed  that  all  of  the 
formal  requirements  for  an  Ada  run  time  environment  (see  section 
2.3.2)  will  have  been  satisfied  by  the  time  any  Ada  compiler  is 
validated  by  the  Ada  Joint  Program  Office.  Hence,  only  the  optional 
features  (such  as  those  mentioned  in  section  2.3.3)  need  be  care¬ 
fully  analyzed  in  this  report.  Unless  stated  otherwise  in  table  2, 
the  characteristics  of  the  ROS-  and  UNIX-based  run  time  environments 
are  believed  to  be  the  same. 

Inspection  of  table  2  will  reveal  that  even  the  most  promising 
of  the  Ada  run  time  environments  (i.e.,  Telesoft's  environment  which 
controls  the  execution  of  machine  code  under  ROS)  does  not  come 
close  to  satisfying  the  needs  of  JAMPS  at  this  time.  However,  since 
Telesoft  claims  that  it  plans  to  implement  new  features  which  will 
rectify  most  of  the  deficiencies  noted  herein,  it  will  be  reasonable 
to  reevaluate  the  situation  in  six  to  nine  months*.  The  current 
status  of  the  ICSC  run  time  environment  suggests  that  it  will  not  be 
ready  for  use  by  JAMPS  programmers  for  quite  some  time.  The 
information  shown  in  table  2  is  based  on  telephone  conversations 
with  representatives  of  Telesoft  and  ICSC,  and  cannot  easily  be 
substantiated  because  published  reports  describing  the  features  of 
the  various  alternative  run  time  environments  are  not  available  from 
the  vendors. 


*Teleaoft,  a  relatively  small  software  house,  is  believed  to  have  a 
current  backlog  of  20  contracts  for  retargeting  its  Ada  compiler  to 
various  different  types  of  computers.  It  appears  that  Telesoft  is 
not  lnj  a  position  to  undertake  an  additional  contract  in  the 
phort/term  to  develop  a  customized  run  time  environment  for  JAMPS. 


Table  2 


Coeparison  of  JAMPS '  Requirements  Versus  Capability 
of  Existing  Ada  Run  Time  Environments 


JAMPS 

Requirements 

Task  Management 
Requirements 


Multiprogramming 


No  restrictions  on 
the  number  of  dif¬ 
ferent  separately- 
scheduled  tasks 

Multitasking 


Expedited  dis¬ 
patching  (character 
echo) 

No  restrictions  on 
size  of  packages, 
tasks,  subprograms 


No  restrictions  on 
the  number  of  "main” 
programs,  with  pro¬ 
visions  for  commu¬ 
nications  between 
"main  programs." 


Telesoft  Run  Time 
Environment 


See  below 


ICSC  Run  Time 
Environment 

No  capabilities  for 
tasking  at  this 
time.  Future  plans 
for  task  management 
are  undefined. 


Not  available  at  this 
time;  the  Priority  Pragma 
is  supposed  to  be  imple¬ 
mented  with  ROS  during 
1984. 

Currently  limited  to  32 
tasks;  this  restriction  is 
is  due  to  be  removed  in 
1984. 

Supports  sharing  of  data 
and  pointers  between  tasks 
(at  most,  256  words  can  be 
exchanged). 

Currently  available,  with 
100  usee  delay  as  an  upper 
bound. 

Currently,  Individual  pack¬ 
ages  are  restricted  to  32 
Kbytes,  but  this  limitation 
is  expected  to  be  removed 
during  1984. 

"Main"  programs  cannot 
run  concurrently;  restrict¬ 
ed  to  one  32-bit  word  for 
communication  between  two 
main  programs. 
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Table  2  (Continued) 

Comparison  of  J AMPS'  Requirements  Versus  Capability 
of  Existing  Ada  Run  Time  Environments 


JAMPS 

Requirements 


Memory  Manages 
Requirements: 


Detection  of  80% 
saturation  of 
dynamic  memory  areas 


No  restrictions  on 
number  of  levels 
of  nested  pro¬ 
cedures 


No  arbitrary  limit 
on  dynamic  memory 
space  allocated  to 
individual  task 
programs. 


File  lock/unlock 
services 


Telesoft  Run  Time 
Environment 


Not  available.  JAMPS 
software  dealgnera  must 
provide  a  workaround 
in  their  applications 
aoftware. 

Currently,  dynamic 
memory  is  exhausted 
after  four  levels  of 
nesting  (when  machine 
runs  out  of  registers 
used  for  this  purpose). 
The  compiler  is  being 
redesigned  to  circum¬ 
vent  this  limitation. 

Currently  fixed  at 
4  Kbytes/task,  32  Kbytes/ 
package.  In  subsequent 
compiler  releases,  the 
programmer  will  be 
permitted  to  statically 
assign  as  much  dynamic 
memory  space  as  his 
program  requires. 

Can  use  Ada's  Rendez¬ 
vous  construct  for  this 
purpose. 


ICSC  Run  Time 
Environment 


Not  available 


Unknown 


No  restrictions 
on  dynamic  memory 
space . 


Same  as  for 
Telesoft. 
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Table  2  (Continued) 

Comparison  of  J AMPS'  Requirements  Versus  Capability 
of  Existing  Ada  Run  Tine  Environments 

JAMPS 

Requirenents 

Telesoft  Run  Time 
Environment 

ICSC  Run  Time 

Environment 

- 

No  restrictions  on 
memory  space  for 
Access  Types  as 
seen  by  individ¬ 
ual  packages,  tasks, 
subprograms 

Not  currently  avail¬ 
able,  but  restriction 
is  due  to  be  removed 
during  1984. 

Same  as  for 

Telesoft. 

Disk-file  access 
either  by  serial 
or  by  indexed- 
sequentlal  addres¬ 
sing  techniques. 

Currently  available. 

Currently  avail¬ 
able. 

Operations 

i 

Data  manipulation 
capabilities  for 
two  dimensional 
arrays . 

Currently  supported. 

Unknown 

Can  perform  opera¬ 
tions  on  disk  records 
without  having  to 
move  them  from  I/O 
buffer  areas  before 
hand. 

Currently  supported. 

Unknown 

- 

Desirable  feature: 

Can  perform  opera¬ 
tions  on  low-level 

I/O  data  (e.g. , 
communications 
data)  without 
having  to  move  the 
data  from  the  I/O 
buffer  areas  before¬ 
hand. 

Not  supported. 

Low-level  I/O 
buffer  space  is 
limited  to  8  Kbytes. 

i 

( 

f 

29 

! 

S  i 

% 

% 

% 
.*  ii 

..V 

V 

Table  2  (Continued) 


Comparison  of  J AMPS'  Requirements  Versus  Capability 
of  Existing  Ada  Run  Time  Environments 


JAMPS 

Requirements 

Telesoft  Run  Time 
Environment 

ICSC  Run  Time 
Environment 

I/O  Management 
Requirements 

Asynchronous  I/O 
for  character  and 
block-oriented 
devices . 

Currently  available. 

Not  currently 
available. 

Text  I/O 

Currently  available. 

Currently  available 

Low-level  I/O 

Currently  available. 

Currently  available 

Device  driver  for 
a  telephone  modem 
connection. 

Not  currently  available. 

Other  device  drivers 
(floppy  disk,  CRT, 
Winchester  disk) 

Currently  available. 

Unknown 

Date/time  Support 

Currently  available; 
time  to  nearest  second. 

Currently  available 

Disk  I/O  driver 
accommodates  indi¬ 
vidual  records  which 
are  up  to  8  Kbytes 
in  length. 

Currently  available. 

Unknown 

System  Initialize- 
tlon  Requirements 

Flush  out  of  1/0 
buffer  areas  (de¬ 
sirable  feature  but 
not  a  requirement) 

Not  available. 

Programs  which  rely  upon 
use  of  uninitialized 
variables  are  erroneous. 

Not  available. 

Table  2  (Concluded) 


Comparison  of  J AMPS'  Requlreaents  Versus  Capability 
of  Existing  Ada  Run  Tine  Environments 


JAMPS 

Requirements 

Telesoft  Run  Time 
Environment 

ICSC  Run  Time 
Environment 

Capability  for 
assigning  logical 
units  to  physical 
devices  (consoles) 

Unknown 

Unknown 

Optimisation  Support 

Can  optimise  run 
time  system  either 
for  faster  execu¬ 
tion  or  for  reduced 
memory  use. 

Currently  available 
with  ROS 

Unknown 

Ability  to  Interface 
Ada-compiled  pro¬ 
grams  with  other 
programs  written  in 
"C"  language;  al¬ 
though  not  an 
absolute  necessity, 
this  feature  is 
highly  desirable. 

Pragma  Interface  to 
to  other  languages 
is  not  supported;  nor 
are  there  any  imsediate 
plans  to  Implement  this 
Pragma. 

Currently  avail¬ 
able. 

Ability  to  use  in¬ 
line  code  in  lieu 
of  procedural  calls 
to  the  run  time 
environment. 

In-line  Pragma  is  not 
currently  available  but 
is  supposed  to  be 
supported  in  1984. 

Unknown 

Suppression  of  Range 
Checks  in  order  to 
Improve  response 
time  performance. 

The  Suppress  Pragma  is 
currently  supported 
by  Telesoft's  compiler. 

Currently  avail¬ 
able. 

31 


2.4  PREDICTED  RUN  TINE  PERFORMANCE 

The  expected  performance  of  Ada- compiled  programs  in  the 
embedded  MC68000  computer  is  a  matter  of  paramount  concern.  Some  of 
the  early  Ada  compiler  implementations  are  reputed  to  produce  very 
inefficient  object  code.  There  are  no  formal  requirements  placed  on 
Ada  compilers  for  object  code  efficiency. 

Run  time  performance  will  be  discussed  as  follows: 

o  Benchmark  neaeuraments  to  determine  execution  times 

o  Context  switching  times 

o  Memory  use 

2.4.1  Benchmark  Measurements  to  Determine  Execution  Times 


One  very  popular  yardstick  for  comparing  the  performance  of 
higher-level  languages  in  various  microcomputers  is  a  simple 
benchmark  program  based  on  the  Sieve  of  Eratoethenes[ 7  J.  This 
program  finds  all  of  the  prime  numbers  between  3  and  16381. 

The  benchmark  test  results  shown  in  table  3  are  only  one  crude 
Indication  that  Telesoft's  Ada/ROS  compiler  implementation  will 
aatlsfy  the  response  time  requirements  for  JAMPS.  It  is  assumed 
that  the  existing  software  written  in  "C"  language  will  perform 
satisfactorily  in  the  MC68000  and  that  on  the  basis  of  the  timing 
data  shown  in  table  3,  the  C  code  and  Ada/ROS  programs  can  be 
expected  to  run  roughly  at  the  same  speed.  It  is  unknown  Just  how 
much  degradation  in  response  time  performance  can  be  expected  if  ROS 
were  to  be  replaced  by  UNIX. 

2.4.2  Context  Switching  Times 

The  time  required  to  respond  to  an  interrupt,  suspend  the 
current  task  and  schedule  the  execution  of  another  task  is  referred 
to  as  "context  switching  time."  In  clumsy  run  time  environments 
based  on  operating  systems  intended  for  use  in  software  development 
systems  (l.e.,  not  for  use  in  real-time  embedded  computer 
applications),  context  switching  tlaes  are  typically  5-10 
milliseconds  in  length;  for  some  types  of  real-time  applications, 
context  switching  tlaes  of  this  length  would  be  intolerable. 

Telesoft  claims  that  its  Ada/ROS  run  tiae  environment  for  the 
MC68000  will  accomplish  context  switching  in  0. 5-1.0  milliseconds, 
and  this  length  of  delay  appears  to  be  quite  ressonable  for  the 
JAMPS  application. 
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Table  3 

Benchmark  Test  Results  Using  the  Sieve  of  Eratosthenes [7  ] 


Computer 

Operating 

System 

Language 

Execution 

Time 

(seconds) 

MC68000,  8  MHz 
(Sun  pa  68K) 

ROS 

Ada  (Telesoft) 

4.4 

MC68000,  8  MHz 
HP-9830 

ROS 

Ada  (Telesoft) 

5.0 

MC68000,  WICAT, 

150  WS 

MCS/UNIX 

C  (Johnson) 

4.71 

MC68000,  Charles 
River  68 

UNOS 

C 

6.3 

MC68000,  8  MHz 

EXOP  MACS 

Not  available 

C  (Whitesmiths) 

9.82 

MC68000,  8  MHz 

Not  available 

Assembly 

0.49 
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The  on-line  and  off-line  JAMPS  software  written  in  "C”  amount 
to  9,953  and  4,944  source  statements  of  C  source  code,  respectively; 
(see  table  5  in  section  4.4).  On  the  basis  of  a  recoding  experiment 
described  in  section  4.3,  it  appears  that  Ada  requires  46Z  more 
source  statements  than  "C”  for  equivalent  functions.  Hence,  14,531 
Ada  source  statements  will  be  required  for  the  JAMPS  on-line 
functions  (a  separate  memory  overlay).  On  the  basis  of  this  same 
experiment,  on  the  average,  each  complete  Ada  source  statement 
generated  24.8  bytes  of  object  code.  It  follows  that  the  online 
applications  software  will  occupy  360  Kbytes*  (14,531  x  24.8  *  360K) 
of  memory.  The  UNIX  and  ROS  run  time  environments  require  an 
additional  260  Kbytes  and  80  Kbytes,  respectively.  Therefore,  JAMPS 
software  written  in  Ada  will  require  a  main  memory  size  of  .75  to 
1.0  megabytes,  and  this  does  not  appear  to  be  a  cause  for  concern. 


2.5  COMPILER  RELIABILITY 

The  object  code  generated  by  immature  compilers  frequently 
doesn't  execute  properly  (i.e.,  is  unreliable).  However,  Telesoft 
has  already  sold  350  of  its  Ada  compilers,  and  their  widespread 
early  use  has  allowed  these  compilers  to  mature  at  an  unusually 
rapid  pace.  The  consenus  is  that  Telesoft  Ada  compilers  are 
reliable  enough  to  be  useful,  although  workarounds  are  frequently 
required  because  significant  features  of  the  Ada  language  are  not 
yet  supported.  Slnger-Librascope[ 8  ],  for  example,  claims  to  have 
successfully  used  a  Telesoft  Ada  compiler  for  the  MC68000  on  two 
different  acquisition  projects. 

Error  diagnostics  generated  by  immature  compilers  are 
frequently  meaningless  to  applications  programmers.  However,  at  the 
AdaTEC  meeting  in  Dallas  (October  1983),  Telesoft  successfully 
demonstrated  that  their  compiler  underlines  the  offending  clauses  in 
erroneous  Ada  source  statements;  references  to  applicable  sections 
of  the  Ada  Language  Reference  Manual  were  observed  to  be  appended  to 
the  faulty  source  statements  as  well.  Nevertheless,  while  using  the 
Telesoft  Ada  compiler  on  the  WICAT  computer  at  MITRE,  a  number  of 
abstruse  (unhelpful)  error  diagnostics  have  been  observed  and 
several  compiler  crashes  have  occurred.  The  apparent  discrepancies 
between  the  demonstration  in  Dallas  versus  the  Telesoft  compiler 
performance  at  MITRE,  Bedford  are  attributed  to  recent  enhancements 
which  are  not  yet  available  in  the  compilers  released  to  the  public. 


The  existing  JAMPS  on-line  software  written  in  "C",  which  does  not 
Include  local  area  network  functions  included  in  the  sizing 
estimate  for  Ada-compiled  programs,  occupies  234  Kbytes. 
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In  part,  the  feasibility  of  duplicating  JAMPS  software  in  Ada 
■ay  hinge  on  the  availability  of  quick  maintenance  support  for  Ada 
software  development  tools.  Telesoft  is  a  small  firm  (15  employees 
as  of  1  February  1983),  and  it  is  uncertain  whether  an  organization 
of  this  size  can  provide  adequate  maintenance  support  to  many  users. 
LabTek  is  an  even  smaller  company  which  sells  systems  including 
HICAT  machines  (based  on  MC68000)  in  combination  with  Telesoft's  Ada 
software  development  tools.  In  the  past,  LabTek  has  generously 
provided  a  lot  of  free  advice  to  MITRE  personnel  when  they  were 
experiencing  problems  using  the  Telesoft  Ada  compiler.  In  many 
Instances,  these  were  programmer  problems,  not  compiler  errors.  It 
has  been  more  difficult  to  obtain  answers  from  Telesoft  directly. 
However,  Telesoft  does  seem  to  be  distributing  improved  versions  of 
its  compilers  at  intervals  of  once  every  two  to  three  months. 


2.6  PHYSICAL  LIMITATIONS  OF  THE  TELESOFT  COMPILER 

The  limitations  of  the  Telesoft  Ada  compiler  have  not  been 
fully  determined.  However,  users  of  the  Telesoft  computer  do  not 
seem  to  be  voicing  many  objections  in  this  regard.  The  following 
data  summarizes  several  telephone  conversations  with  marketing 
representatives: 

o  Maximum  number  of  lines  of  source  code  per  compilation 
module  greatly  exceeds  any  requirement  which  JAMPS  might 
Impose,  and  therefore  is  not  regarded  as  a  potential  area 
for  concern. 

o  Maximum  size  of  symbol  table  <  128  Kbytes. 

o  Compilation  speed  <  300  lines  of  source  code/minute. 

o  Maximum  number  of  simultaneous  compilations  (in  parallel  on 
same  host  computer)  -  1.  This  limitation  is  significant. 
The  schedule  for  reimplementing  JAMPS  software  in  Ada  needs 
to  be  stretched  out  because  the  number  of  programmers  who 
can  access  the  host  computer  will  be  quite  limited. 
Alternatively,  more  than  one  host  computer  might  be  used, 
but  that  approach  will  compound  the  problems  of  software 
configuration  control. 
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SECTION  3 


COST  FACTORS 


Factors  which  need  to  be  taken  into  account  while  preparing 
cost  estimates  for  duplicating  JAMPS  software  in  Ada  are  discussed 
as  follows: 

o  System  requirements  specification 
o  Contract  monitoring  support 
o  Software  reusability 
o  Training 

o  Software  development  facilities 
o  Software  architecture 
o  Testing 

o  Performance  measurements 

o  Redesign  of  programs  which  generate  "source  tapes" 
o  Configuration  management 


3.1  SYSTEM  REQUIREMENTS  SPECIFICATION 

The  requirements  specification  for  JAMPS  was  not  prepared  in 
accordance  with  military  standards  and  in  some  ways  is  not  entirely 
appropriate  for  use  by  an  independent  contractor  for  an  acquisition 
program.  However,  with  ample  support  from  the  government,  an 
amended  version  of  the  requirements  specification  will  suffice.  The 
requirements  baseline  for  JAMPS  is  expected  to  be  fairly  stable 
during  the  next  several  years. 

Inasmuch  as  The  MITRE  Corporation  has  already  developed  a 
prototype  model  of  the  JAMPS  system,  it  is  anticipated  that  the 
amount  of  system  engineering  work  to  be  accomplished  by  the  con¬ 
tractor  will  be  less  than  normal  for  a  project  of  this  size. 
Functional  allocations  between  hardware  and  software  have  already 
been  determined.  The  operator  interface  is  well  defined. 


3.2  CONTRACT  MONITORING  SUPPORT 

An  unusually  high  level  of  contract  monitoring  support  will  be 
necessary  for  several  reasons: 

o  It  is  assumed  that  an  entirely  new  set  of  disk  file 


structures  will  be  defined  for  JAMPS,  and  this  will  not  be 
an  easy  task.  The  new  file  structures  should  be  designed  to 
facilitate  the  use  of  Ada  and  must  be  considered  when  the 
government  undertakes  redesign  of  the  off-line  programs  at 
the  Langley  Data  Processing  Center. 

Many  things  need  to  be  done*  to  establish  and  monitor  a 
contract  involving  the  use  of  Ada;  there  is  little 
precedent  within  ESD  which  can  be  drawn  upon  for  these 
purposes. 

It  is  anticipated  that  the  JAMPS  efforts  to  use  Ada  will 
attract  widespread  attention  within  ESD.  Documents 
describing  the  "software  methodology  while  designing  in  Ada" 
and  "lesions  learned  while  applying  Ada"  will  be  required  in 
addition  to  the  standard  forms  of  software  documentation 
which  are  normally  required  of  DoD  contractors. 


3.3  SOFTWARE  REUSABILITY 

The  strictness  of  Ada  compiler  validation  reduces,  but  does  not 
eliminate,  the  problems  of  software  portability  and  reusability.  It 
costs  more  and  takes  longer  to  prepare  software  that  is  easily 
reusable,  regardless  of  which  programming  language  is  used[9  ]. 
Programming  standards  and  conventions  which  require  isolation  of 
machine  dependencies  (e.g.,  precision  of  fixed  point  arithmetic), 
compiler  dependencies  (e.g.,  differences  in  computational 
efficiency),  and  run  time  environment  dependencies  (e.g.,  expedited 
dispatching)  must  be  rigidly  enforced.  It  is  intuitively  estimated 
that  designing  for  software  reusability  will  Increase  development 
costs  by  20X  and  that  this  will  more  than  pay  for  itself  if  JAMPS 
software  is  to  be  reused  in  numerous  other  systems.  There  is  no 
empirical  data  available  to  support  this  intuitive  estimate. 


*Preparation  of  RFP,  IFPP,  Proposal  Evaluation  Criteria,  policy 
decisions  relative  to  the  use  of  Ada-based  Program  Design  Language 
in  formal  software  documentation,  guidelines  for  Ada  programming 
style  (standards  and  conventions),  etc. 


It  is  noted  that  the  existing  software  written  in  MC"  was  not 
prepared  with  reusability  in  mind,  and,  as  a  consequence,  is 
expected  to  be  fairly  awkward  to  incorporate  in  other  systems.  It 
is  also  observed  that  the  reusability  of  JAMPS  software  written  in 
Ada  will  be  diminished  by  any  dependence  upon  the  availability  of 
specific  features  in  an  Ada  run  time  environment  which  are  not 
required  by  MIL-STD-1815A  (Ada  Language  Reference  Manual). 

3.4  TRAINING 

Program  management  and  contractor  personnel  will  probably  need 
extensive  training,  both  in  the  Ada  syntax  and  especially  in  the 
software  engineering  principles  upon  which  the  Ada  language  is 
based.  Every  individual  involved  should  have  at  least  four  weeks  of 
formal  training  in  Ada.  Additional  training  in  the  preparation  of 
reusable  software  is  highly  recommended.  It  is  also  suggested  that 
the  consulting  services  of  an  Ada  expert  be  made  available  to  the 
JAMPS  project,  especially  during  the  early  stages  of  development; 
this  individual  will  critique  the  first  attempts  by  JAMPS 
programmers  to  use  Ada. 

DoD  policy  disallows  programmer  training  as  an  expense  which 
can  be  directly  charged  to  an  acquisition  project*.  Nevertheless, 
during  the  transition  period  in  which  most  programmers  will  be 
unfamiliar  with  the  Ada  language,  it  is  inevitable  that  some  amount 
of  training  will  be  required. 


3.5  SOFTWARE  DEVELOPMENT  FACILITIES 

The  Telesoft  Ada  compiler  requires  a  1-megabyte  main  memory  and 
a  15-megabyte  disk  storage  unit.  Configuration  management  of  Ada 
source  and  object  code  files  is  expected  to  increase  disk  storage 
requirements  even  further.  It  is  assumed  that  at  least  two  standa¬ 
lone  software  development  facilities  will  be  acquired  and  maintained 
throughout  the  effort  to  duplicate  JAMPS  software  in  Ada.  Much  of 
the  testing  of  Ada  programs  will  take  place  on  the  host  computer 
under  the  control  of  a  symbolic  debugger.  Highly  optimized  Ada 
object  code  is  generally  undecipherable  and  cannot  easily  be  patched 
in  machine  language  format  in  the  target  computer.  Therefore,  the 
host  computer  (software  development  facility)  should  include  several 
consoles  to  support  parallel  efforts  by  various  programmers.  Even 

*The  Director  of  the  Ada  Joint  Program  Office  made  this  statement  at 
the  AdaTEC  meeting  in  Dallas  on  19  October  1983. 


though  only  one  programmer  will  be  able  to  u8e  the  Telesoft  Ada 
compiler  at  any  one  time,  other  progratmners  can  do  other  chores, 
such  as  text  editing,  on  the  host  computer  (in  parallel)  while  a 
compilation  is  underway. 


3.6  SOFTWARE  ARCHITECTURE 

To  take  full  advantage  of  the  features  inherently  available 
with  the  Ada  language,  the  software  architecture  for  JAMPS  must  be 
fully  redesigned.  There  is  little  point  in  recoding  on  a  module- 
per- module  basis  with  existing  software  written  in  "C”;  this  would 
result  in  Ada  code  that  would  be  both  inefficient  and  difficult  to 
reuse  in  other  systems. 

On  the  basis  of  performance  measurements,  it  has  been 
determined  that  the  response  time  performance  of  JAMPS  is  largely 
determined  by  the  number  of  disk  accesses  required  for  various  types 
of  messages.  To  reduce  the  number  of  disk  accesses,  the  existing 
disk-file  structure  needs  to  be  changed  extensively,  combining 
certain  files  together  and  eliminating  data  stored  redundantly  in 
two  or  more  files.  The  design  of  variant  record  formats  should  take 
into  consideration  the  needs  of  generic  Input/output  routines 
written  in  Ada.  The  record  formats  which  currently  exist  in  JAMPS 
will  be  difficult  to  accommodate  in  Ada. 


3.7  TESTING 

It  is  proposed  that  redesign  of  disk  file  structures  will  be 
accomplished  in  "C"  prior  to  the  reimplementation  in  Ada,  and  that 
the  disk  file  structures  used  by  programs  written  in  "C”  and  in  Ada 
will  be  kept  exactly  the  same.  This  will  reduce  the  risks 
associated  with  Ada  by  making  it  possible  to  partition  the 
Integration  and  testing  of  Ada  software  into  two  separate  efforts: 

o  New  (unproven)  off-line  programs  written  in  Ada  can  be  used 
to  both  populate  and  validate  the  disk-resident  files; 
afterwards,  proven  on-line  programs  written  in  "C"  can  be 
used  to  verify  that  the  disk  files  have  been  initialized 
appropriately. 


Proven  off-line  programs  written  in  "C"  can  be  used  to 
populate  and  validate  the  disk-resident  files;  afterwards, 
new  (unproven)  on-line  programs  written  in  Ada  can  be 
exercised  with  high  assurance  that  the  data  obtained  from 
disk  during  on-line  operations  is  correct. 
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This  approach  will  permit  integration  testing  in  parallel  for  off¬ 
line  and  on-line  programs  written  in  Ada,  and  will  reduce  the  over¬ 
all  time  to  accomplish  the  duplication  effort.  If  this  approach  is 
not  adopted,  the  software  development  schedules  should  be  extended 
at  least  four  months. 


3.8  PERFORMANCE  MEASUREMENTS 

Special  software  tools  should  be  developed  by  the  Air  Force 
for  performance  measurements  on  Ada  programs  in  the  MC68000  because 
such  tools  are  not  expected  to  be  made  available  by  software  vendors 
in  the  immediate  future.  As  a  prerequisite  for  developing  these 
tools,  the  government  will  need  to  acquire  the  source  listings  for 
the  Ada  run  time  environment  which  has  been  selected. 


3.9  REDESIGN  OF  PROGRAMS  WHICH  GENERATE  "SOURCE  TAPES" 

It  is  assumed  that  the  government  will  undertake  the  redesign 
of  off-line  programs  which  process  the  "JINTACCS  tapes."  These 
revised  prograns  will  obviate  any  need  for  YACC  and  LEX  capabilities 
as  presently  made  available  by  UNIX  to  the  IBLD  programs  in  JAMPS. 

It  is  further  assumed  that  the  feasibility  of  using  YACC  and  LEX  in 
conjunction  with  Ada-compiled  programs  is  extremely  doubtful. 
Therefore,  it  would  be  necessary  to  duplicate  YACC  and  LEX  functions 
in  Ada  if  the  government  is  unwilling  to  assume  responsibility  for 
the  proposed  changes. 

If  JAMPS  were  redesigned  to  bypass  any  need  for  support  from 
the  Data  Processing  Center  at  Langley  AFB,  accepting  the  JINTACCS 
tape  as  input  Instead  of  the  "source  tape,"  then  the  functions 
currently  provided  by  2500  lines  of  "C”  source  code  at  the  Langley 
Data  Processing  Center  must  somehow  be  accommodated  in  JAMPS.  In 
addition,  the  YACC  and  LEX  functions  (2,670  and  2,820  lines  of  ”C" 
respectively)  and  the  IBLD  functions  (in  JAMPS)  which  would  other¬ 
wise  have  been  absorbed  by  the  Langley  Data  Processing  Center  (3,000 
lines  of  "C")  must  be  considered  while  scoping  the  size  of  the 
effort  to  duplicate  JAMPS  software  in  Ada. 


3.10  CONFIGURATION  MANAGEMENT 

Telesoft  does  not  currently  provide  tools  for  Ada  software 
configuration  control,  nor  does  it  intend  to  begin  development  of 
such  tools  during  1984.  Nevertheless,  it  is  highly  desirable  to 
have  such  tools  for  keeping  track  of  dependencies  between  different 
versions  of  separately-compiled  modules.  Accordingly,  the  Air  Force 


will  need  to  develop  its  own  configuration  management  tools  In 
support  of  JAMPS  software  development  in  Ada. 
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SECTION  A 


ESTIMATES  OF  THE  NUMBER  OF  ADA  SOURCE  STATEMENTS 
TO  BE  DEVELOPED 


Estimates  of  the  number  of  Ada  source  statements  to  be 
developed  were  determined  in  the  following  manner: 

o  The  actual  number  of  lines  of  "C"  source  code  in  the 

existing  JAMPS  system  was  computed  with  comment  statements 
excluded. 

o  Adjustments  were  made  to  convert  lines  of  "C“  code  into 
equivalent  complete  source  statements  written  in  the  "C” 
language. 

o  Adjustments  were  introduced  to  reflect  the  expected  effects 
of  simplifying  the  functional  requirements  for  JAMPS  off¬ 
line  programs  via  "source  tape"  redesign.  Allowances  were 
made  for  new  local  area  network  requirements  not  yet  incor¬ 
porated  into  the  existing  JAMPS  software  written  in  "C". 

o  A  representative  example  of  "C"  code  from  JAMPS  was  recoded 
in  Ada,  yielding  a  planning  factor  for  expressing/estimating 
Ada  source  statements  in  terms  of  equivalent  (existing)  "C" 
statements. 

o  Estimates  for  Ada  source  statements  to  be  developed  were 
computed  by  multiplying  a  conversion  factor  (from  the 
recoding  experiment)  times  the  adjusted  number  of  ”C"  source 
statements. 

The  validity  of  estimates  which  are  based  on  an  extrapolation 
from  the  results  of  a  recoding  experiment  is  highly  questionable. 

It  is  quite  possible  that  if  the  recoding  experiment  had  been 
conducted  by  some  other  programmer  and/or  the  representative  example 
selected  from  existing  JAMPS  software  to  be  recoded  in  Ada  had  been 
different,  then  the  estimates  for  Ada  source  statements  to  be 
developed  might  change  substantially.  However,  the  more  traditional 
approach  for  estimating  the  size  of  a  software  job,  based  on  the 
cumulative  sum  of  intuitive  judgments  about  the  sizes  of  various 
modules,  is  also  prone  to  large  errors.  Regardless  of  which  method 
is  followed,  an  error  of  25Z  while  estimating  "source  statements"  to 
be  developed  is  entirely  possible. 


4.1  SIZING  ANALYSIS  FOR  EXISTING  JAMPS  SOFTWARE 


The  results  of  a  survey  of  JAMPS  code  written  in  "C"  language 
are  depicted  in  table  4;  coament  statements  are  not  included.  The 
data  in  table  4  corresponds  with  the  "C"  implementation  on  the  DEC 
11/23  and  will  be  subject  to  minor  changes  while  shifting  over  to 
the  MC68000. 


4.2  ADJUSTMENTS 

The  actual  "source  data"  shown  in  table  4  has  been  adjusted  in 
several  ways,  yielding  the  results  depicted  in  table  5.  The  line 
counts  in  table  4  for  "C"  code  Include  certain  lines  which  contain 
nothing  more  than  a  single  bracket,  "[".  For  purposes  of  cost 
estimation,  these  lines  should  be  treated  just  like  "comment"  lines, 
(i.e.,  ignored).  On  the  basis  of  an  examination  of  a  representative 
example  of  the  "C”  code,  it  is  estimated  that  14Z  of  all  "C”  source 
code  lines  shown  in  table  4  correspond  to  simple  "brackets"  and 
should  be  discounted  accordingly. 

The  data  shown  in  table  4  is  expressed  in  terms  of  "lines  of 
code.”  It  is  observed  that  in  numerous  instances,  a  single  JAMPS 
source  statement  expressed  in  "C"  occupies  two  or  sometimes  three 
lines.  This  is  a  matter  of  programing  style.  Some  programmers 
prefer  to  write  one  source  statement  per  line;  others  write  indi¬ 
vidual  source  statements  using  several  lines.  For  purposes  of 
software  cost  estimation,  it  is  more  meaningful  to  use  complete 
source  statements,  not  just  "lines  of  code.”  For  this  reason,  the 
data  in  table  4  has  been  further  adjusted  to  remove  the  efforts  of 
multiple  lines  per  source  statement.  On  the  basis  of  an  inspection 
of  JAMPS  code,  it  is  estimated  that  16Z  of  the  lines  of  "C"  should 
be  discounted  as  "spillovers"  from  preceding  lines.  In  summary,  the 
"number  of  lines”  of  "C"  code  has  been  reduced  by  30Z  (14Z  +  16Z), 
while  reexpressing  the  sizing  data  in  terms  of  "source  statements" 
(table  S). 

It  is  estimated  that  3000  lines  of  IBLD  (off-line)  "C”  code  can 
be  eliminated  by  redesigning  the  "source  tape"  format.  In  essence, 
more  of  the  burden  of  initializing  JAMPS  will  be  assumed  by  the 
Langley  AFB  Data  Processing  Center  in  the  future.  In  the  event  that 
the  government  does  not  agree  with  this  assumption,  then  the  3000 
lines  of  IBLD  code  (i.e.,  off-line  JAMPS  functions)  plus  an 
additional  5540  lines  of  ”C”  code  in  UNIX  (YACC,  LEX)  must  be 
considered  as  part  of  the  effort  to  duplicate  JAMPS  software  in  Ada. 
If  JAMPS  bypasses  the  Langley  AFB  Data  Processing  Center  altogether, 
accepting  the  JINTACCS  tape  directly  as  input,  then  the  functions 


Table  4 


Sizing  Analysis  for  Existing  Software  Written  in  "C" 


Code  Source  Lines  Memory  Utilization* 


JAMPS  Off-Line  Programs 

IBLD  Programs  7,736 

Test  Programs  2,327 

(consistency/ 
completeness) 


10,063 

JAMPS  On-Line  Programs 

Display  8,447 

Communications  1,077 

Remote  Functions  3,694 

(repeated  as  in-line 
code) 


13,218 


Not  available 
Not  available 


89,704 

23,256 

121,536 


234,196 

Bytes  of  on-line 
executable  code, 
exclusive  of 
UNIX. 


Total  for  JAMPS  23,281 

Off-Line  programs  which  2,500 

generate  "source  tapes” 


♦Memory  utilization  is  based  on  "C"  compiler  for  the  DEC  11/23 
computer. 


Table  5 


Sizing  Data  with  Adjustments 


"C"  Source  Lines  "C"  Source  Statements 


JAMPS  On-Line  Functions 

Existing  Functions  13,218 

Allowance  for  Local  1,000 

Area  Network  Functions 


Equivalent  lines  to  14,218 

be  recoded  in  Ada 

JAMPS  Off-Line  Functions 

Existing  Functions  10,063 

Less  simplifications  -  3,000 

due  to  new  “source 

tape”  format  _ 

7,063  "Best  Case” 


9,953 


4,944 


If  Langley  AFB  Data  Processing  Center  is  unwilling 
to  revise  the  "source  tape”  format: 


Existing  Off-Line  JAMPS  10,063 

Functions 

LEX  2,870 

YACC  2,670 


Total  off-line  code  to 
be  duplicated  in  Ada 


15,603  "In  Between  Case"  10,922 


If  JAMPS  Bypasses  Langley  AFB  Data  Processing  Center 
Altogether: 


Existing  Off-Line 

10,063 

Functions 

LEX 

2,870 

YACC 

2,670 

Programs  which  generate 

"source  tapes" 

2,500 

Total  off-line  code  to 
be  duplicated  in  Ada 


18,103  "Worst  Case" 
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currently  performed  by  2500  lines  of  "C"  code  at  Langley  AFB  must  be 
accommodated  in  JAMPS. 


4.3  A  REPRESENTATIVE  EXAMPLE  OF  "C"  RECODED  IN  "ADA" 

A  representative  example  of  JAMPS  software  written  in  “C”  has 
been  recoded  in  Ada.  The  complete  example  in  both  languages  is 
provided  in  Appendix  A,  and  the  results  are  suomarized  in  table  6. 
Owing  to  the  incompleteness  of  the  Telesoft  Ada  compiler  for  the 
MC68000,  many  features  of  the  language  had  to  be  avoided  during 
compilation.  Hence,  the  example  had  to  be  recoded  using  two 
different  methods: 

o  Recoding  without  any  restrictions  (i.e.,  using  features  of 
the  full  Ada  language).  This  method  produced  a  conversion 
factor  which  can  be  used  for  determining  the  number  of  Ada- 
source  statements  to  be  developed  on  the  basis  of  equivalent 
source  statements  written  in  "C". 

o  Recoding  in  Ada,  circumventing  deficiencies  in  the  compiler 
whenever  necessary.  (Approximately  one-third  of  the  code 
written  using  the  full  Ada  language  produced  error 
diagnostics  during  compilation;  therefore,  the  code  that 
will  not  compile  appears  as  comments  in  the  listing  shown  in 
Appendix  A.)  This  second  method  produced  code  which  could 
be  compiled  error-free,  and  the  results  can  be  used  for 
estimating  memory  requirements  for  programs  written  in  Ada. 

The  results  of  the  experiment  suggest  that  Ada  as  a  language  is 
more  verbose  than  "C"  because  1.46  source  statements  in  Ada  were 
found  to  be  functionally  equivalent  to  1.0  source  statements  in  "C”. 
This  conclusion  is  somewhat  misleading  because  the  number  of 
executable  source  statements  written  in  "C"  and  Ada  were  roughly 
comparable  (134  versus  125,  respectively).  The  greatest  difference 
between  the  number  of  source  statements  using  the  two  languages  Is 
attributable  to  the  explicit  data  declaration  statements  which  Ada, 
unlike  "C",  requires  for  defining  the  disk-resident  data  records. 

In  "C",  data  record  formats  are  implicitly  defined  in  the 
executable  code  rather  than  in  explicit  data  declaration  statements. 
During  the  recoding  experiment,  trying  to  fathom  Implicit  record 
formats  proved  to  be  fairly  difficult,  leading  to  the  conclusion 
that  Ada  software  would  be  easier  to  maintain  than  "C"  software. 
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Table  6 


Conversion  from  "C"  to  Ada 


Source  Statements 


"C"  Ada 


JAMPS  167  244 

Recoding 

Experiment 


Sieve  of  23  34 

Eratosthenes 


Conclusion:  1  Source  Statement  of  “C"  source  code  ■  1.46  source 
statements  in  Ada. 


244 

167 


1.46 


Each  source  statement  In  Ada  generates,  on  average,  24.8  bytes  of 
object  code  (see  appendix  A). 


4.4  ESTIMATES  OF  THE  NUMBER  OF  ADA  SOURCE  STATEMENTS  TO  BE 
DEVELOPED 

The  estimated  number  of  Ada  source  statements  to  be  developed 
is  computed  in  table  7.  Depending  on  what  assumptions  are  made 
about  the  "source  tape"  format,  the  estimated  number  of  Ada  source 
statements  ranges  from  23,939  to  35,222. 


Table  7 


Estimates  OF  Source  Statements  of  JAMPS  Source  Code 
to  be  Developed  in  Ada 


“C"  Ada 

Off-Line  Functions 


Best  Case 

4,944 

7,218 

In-Between  Case 

10,922 

15,946 

Horst  Case 

12,672 

18,501 

On-Line  Functions 

9,953 

14,531 

Configuration  Management  Tools 

1,000 

1,460 

Performance  Measurement  Tools 

500 

730 

Totals 

Best  Case 

16,397 

23,939 

In-Between  Case 

22,375 

32,667 

Worst  Case 

24,125 

35,222 

Conversion  Factor:  1  source  statement  of  ”C”  ■  1.46  source 

statements  of  Ada. 
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SECTION  5 


ADA  IMPLEMENTATION  PLAN 


A  tentative  plan  for  duplicating  JAMPS  software  in  Ada  is 
presented  below.  Basic  assumptions  have  been  made  as  follows:  (1) 
a  contractor  will  undertake  the  bulk  of  the  effort  involved;  and  (2) 
300-series  procurement  regulations  and  practices  will  be  followed. 
If,  instead,  the  standard  ESD  acquisition  practices  were  adopted, 
based  on  800-series  regulations,  it  is  expected  that  the  cost  of 
duplicating  JAMPS  software  in  Ada  would  rise  substantially,  perhaps 
even  double. 


5.1  MANPOWER  REQUIREMENTS 

Estimated  manpower  requirements  for  various  tasks  are  shown  in 
table  8.  This  table  reflects  recent  experience [10, 11]  in  applying 
the  Ada  language;  the  amount  of  effort  expended  during  preliminary 
design  is  above  average  and  the  amount  of  effort  consumed  during 
Integration  and  testing  is  below  average  when  Ada  is  compared  with 
other  higher  order  languages  (see  figure  4).  Inasmuch  as  JAMPS  has 
already  been  written  in  "C",  the  contractor  is  not  expected  to 
undertake  the  usual  level  of  effort  for  requirements  analysis;  such 
things  as  operator-interface  studies  will  already  have  been 
completed  by  MITRE  and  need  not  be  repeated.  Figure  4  illustrates 
the  differences  between  manpower  allocations  for  a  "typical” 
acquisition  program  and  those  assumed  for  the  JAMPS  implementation 
in  Ada. 

Very  little  is  available  in  the  way  of  data  and  models  to 
support  software  conversion  estimation[12  ] .  Typical  productivity 
during  new  development  using  higher  order  languages  is  300  delivered 
source  statements  per  man-month.  If  JAMPS  software  is  completely 
redesigned  and  fully  rewritten  in  Ada,  then  this  would  be  tantamount 
to  a  new  development  effort  —  not  a  software  conversion  Job.  Owing 
to  the  complexity  of  the  language  and  the  lack  of  programmers 
experienced  in  Ada,  it  will  be  assumed  for  purposes  of  this  study, 
that  programmer  productivity  in  Ada  will  be  250  delivered  source 
statements  per  man  month. 
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Table  8 

Ada  Implementation  Plan 


Level* 

of 


Effort 

(man 


Task 

Description 

Responsibility 

months) 

1 

Update  JAMPS  System  Performance 
Requirements 

Government 

1 

2 

Update  JAMPS  User's  Guide 

Government 

2 

3 

Prepare  IFPP 

Government 

8 

4 

Prepare  RFP/SOW 

Government 

8 

5 

Reevaluate  Feasibility  of  Duplicating 
JAMPS  Software  in  Ada  (to  be  accom¬ 
plished  7/1/84) 

Government 

1 

6 

Source  Selection  Support 

Government 

4 

7 

Contract  Monitoring  Support 

Government 

21 

8 

Redesign  the  Disk  File 

Structures 

Government 

12 

9 

Redesign  Existing  Programs  in  "C"  to 

Use  New  File  Structures 

Government 

36 

10 

Redesign  the  Format  of 

"Source  Tape" 

Government 

3 

11 

Redesign  Off-line  Programs  Which  Generate 
"Source  Tapes"  (50Z  Redesign) 

Government 

9 

12 

Acquire,  Install,  Demonstrate,  and 
Maintain  Ada  Software  Development 
Facility 

Contractor 

12 

13 

Conduct  Benchmark  Measurements  to  Deter¬ 
mine  Efficiency  of  Ada  Compiled  Code 

Contractor 

4 

14 

Requirements  Analysis 

Contractor 

7 

15 

Preliminary  Design  ] 

1 

Contractor 

26 

16 

Detailed  Design  < 

|  On-line 

Contractor 

18 

17 

Code  and  Debug  ( 

Programs 

Contractor 

15 

18 

Development  Testing  ( 

'  for  JAMPS 

Contractor 

14 

19 

Validation  Testing  and ' 
Demonstration  1 

1 

Contractor 

12 

*Ba8ed  on  "optimistic  assumptions 


Table  8  (concluded) 


Level 

of 

Effort 

(man 


Task 

Description 

Responsibility 

months) 

20 

Requirements  Analysis  ) 

i 

Contractor 

4 

21 

Preliminary  Design 

| 

Contractor 

13 

22 

Detailed  Design  / 

Contractor 

9 

28 

Code  and  Debug  / 

1  Off-line 

Contractor 

7 

24 

Development  Testing  \ 

i  Programs 

Contractor 

7 

25 

Validation  Testing  and 
Demonstration  ' 

for  JAMPS 

Contractor 

6 

26 

Prepare  Formal  Validation 

Test  Procedures 

Government 

6 

27 

Conduct  Validation  Tests 

Government 

4 

28 

Conduct  (2)  Timing/Sizing  Analyses 

Contractor 

** 

29 

Document  Potential  Pitfalls  to  be 
Avoided  While  Attempting  to  Reuse 
JAMPS  Software 

Contractor 

** 

30 

Document  Ada  Software  Methodology 
Adopted 

Contractor 

** 

31 

Design,  Code,  Test  Document 
Configuration  Management  Tools 

Contractor 

10 

32 

Design,  Code,  Test,  Document 
Performance  Measurement  Tools 

Contractor 

4 

33 

Training  in  Use  of  Ada 

Contractor 

** 

34 

Training  in  Use  of  Ada 

Government 

0 

35 

Document  Lessons  Learned  While 

Maintaining  an  Acquisition  Program 
Using  Ada 

Government 

3 

36 

Support  to  OED  Demonstration 

Government 

3 

37 

Management 

Contractor 

21 

38 

Software  Quality  Assurance 

Contractor 

** 

39 

C5  Software  Documentation 

Contractor 

** 

♦♦Included  indirectly  in  man-month  estimates  for  software  development 
(tasks  14-25) - 


Figure  A.  Compares  the  Work  Breakdown  for  a  Typical  Medium  Sized  Acquisition  Program 
(Based  on  a  HOL  Other  Than  Ada)  with  the  Work  Breakdown  Structure  Assumed 
for  Duplicating  JAMPS  Software  Using  Ada.  [12] 


From  section  4,  it  is  estimated  that  a  total  of  23,939  Ada 
source  statements  need  to  be  developed  by  the  contractor: 


On-Line  Programs  (redesign) 
Off-Line  Programs  (best  case) 
Tools  (new  design) 


14,531 

7,218 

2,190 

23,939 


23, 939-tg.rce. .statement. -  -  120  _  for  .oftvare 

250  source  statements  per  man-month  development  doting 

the  preliminary 
design  through  in¬ 
tegration  testing 
phases « 

From  figure  4,  preliminary  design  through  integration  testing 
constitutes  79Z  of  the  total  software  development  effort;  activities 
such  as  requirements  analysis  and  formal  demonstrations  represent 
the  remainder  of  the  effort.  Thus, 


120  mm 
.79 


151  mm  will  be  required  for  the  total  software  effort 
by  the  contractor. 


The  individual  efforts  by  the  contractor  for  development  of  on-line, 
off-line,  and  tool  software  are  computed  to  be  92  mm,  45  mm,  and  14 
mm,  respectively. 

The  151  mm  estimate  for  software  development  efforts  by  the 
contractor  includes,  among  other  things,  tasks  such  as  software 
documentation,  timing/sizing  studies,  and  software  quality 
assurance.  It  does  not,  however,  include  the  maintenance  of 
software  development  facilities,  contract  administration,  etc.,  and 
when  these  other  factors  (see  table  8)  are  taken  into  account,  the 
total  manpower  requirements  for  the  contractor  for  all  activities 
amount  to  188  mm.  Additional  efforts  to  be  performed  by  the 
government  personnel  are  estimated  to  require  121  mm. 
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5.2  SCHEDULING  REQUIREMENTS 


A  Gannt  chart  for  duplicating  JAMPS  software  in  Ada  is 
presented  in  figure  5.  The  tasks  in  the  Gannt  chart  are  defined  in 
table  8.  This  chart  indicates  that  the  contractor's  efforts  will  be 
completed  in  21  months: 

Requirements  Analysis  months  0-4 

Software  design,  development,  months  4-19* 

and  integration  testing 

Acceptance  testing,  by  the  months  19-21 

government 


Operational  effectiveness 
demonstration 


months  21-23 


It  is  assumed  that  off-line  and  on-line  programs  will  be  developed 
and  tested  independently  of  one  another  (see  section  4.8). 


*The  results  of  the  Cocomo  model  projections  suggest  that  software 
design,  development,  and  integration  testing  will  only  require  12.9 
months  (see  section  6.2). 
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Figure  5.  GANNT  Chart  for  Duplicating  JAMPS 
Software  in  Ada  (concluded) 


SECTION  6 


COST  ESTIMATION 


The  cost  estimates  for  the  contractor's  effort  to  duplicate 
JAMPS  software  In  Ada  have  been  determined  by  two  Independent 
methods : 

Method  1  -  Software  cost  estimates  have  been  computed  by 

multiplying  manpower  estimates  (see  table  8)  times 
assumed  labor  rates  (which  include  general  and 
administrative  costs). 

Method  2  -  Prediction  of  software  development  costs  via  the 
Cocomo  model.  The  second  set  of  results  will  be 
used  for  purposes  of  comparison  (i.e.,  for  assessing 
the  reasonableness  of  the  estimates  generated  by 
Method  1). 


6.1  METHOD  1:  MANPOWER  REQUIREMENTS  MULTIPLIED  BY  ASSUMED  LABOR 
RATES 

According  to  Reference  13,  microcomputer  programmers  were  paid 
annual  salaries  during  1983  as  follows: 


Experience  (Years) 


Salary  ($K) 


For  purposes  of  this  study,  an  annual  salary  of  $30K  will  be 
assumed.  To  this  figure,  128%  needs  to  be  added  for  overhead  and 
20%  for  general  and  administration  expenses.  Hence,  the  cost  per 
man-month  is  computed  to  be  $6,200.00 

Optimistic  and  pessimistic  estimates  for  duplicating  JAMPS 
software  in  Ada  are  depicted  in  tables  9  and  10,  respectively. 
Taking  the  average  of  the  optimistic  and  pessimistic  estimates,  the 
total  cost  to  duplicate  JAMPS  software  in  Ada  is  projected  to  be 
$4 , 486K. 


Table  9 


Optimistic  Cost  Estimate 

Estimate  with 
20 X  Adjustment 
Because  of  Soft¬ 
ware  Reusability 
Requirements  and 
6Z  Incentive  Fee 


Contractor  188  x  6,200  -  $936K  $1,1 79K 

Government  85*  x  9,166  *  $  779K 

Software  Development  $  50K 

Facility  (Labtek[  14]) 

Training  by  Consulting  0 

Firm 

Consulting  Services  $  100K 

Source  Listing  for  Ada  $  13K 

Run  Time  Environment 

Management  Reserve  (25Z)**  $  530K 


$2,651K 

Co.t  per  source  sc.cs.enc  -  $110.74/sourcs 

statement 

Programmer  Productivity  ”  250  source  statements/mm. 


♦Task  9,  Redesign  of  Existing  Programs  in  "C"  to  use  new  file 
structures,  has  been  omitted  from  the  "Optimistic  Cost  Estimate". 

**A  management  reserve  of  25Z  is  consistent  with  ESD  practice  for 
software  redesign. 


Initial 

Estimate 

via 

Man-Months  x  $/MM  Method  1 


Table  10 


Pessimistic  Cost  Estimate 


Estimate  with 
50%  Adjustment 
for  Software  Re- 
Inltial  usability  and  6 Z 

Estimate  Adjustment  for 

via  Contractor  Award 

Man-Months  x  $/MM  Method  1  Fee _ _ 


Contractor  381* 

Government  121 

Software  Development 
Facility 

Training  by  Consulting 
Firm 

Consulting  Services 
Source  Listing  for  Ada 
Run  Time  Environment 
Management  Reserve  (25%) 


x  6,200  -  $2, 362K  x  1.56  -  $3,685K 
x  9,166  $1 ,109K 

$  50K 

$  50K 

$  150K 

$  13K 

$1,264K 


Cost  Per  Source  Statement 


$6,321K _ 

35,222  Statements 


$6,321K 

$179.46 


Programmer  Productivity  ■  129.4  Source  Statements/mm  (Per  Cocomo 
Model) 


35,222  Source  Statements 
129.4  s.s/mm 


272  mm  for  preliminary  design  through 
integration  and  testing 


— jz  ■  344  mm  total  S/tf  development  effort 
*  +37  mm  for  contract  administration  etc. 

381  total  for  contractor 


6.2  METHOD  2:  COST  ESTIMATION  VIA  THE  COCOMO  MODEL 

The  Cocomo  model[15]  has  been  applied  as  a  means  of  verifying 
the  validity  of  cost  and  schedule  estimates  shown  previously  herein. 
Inputs  to  the  Cocoao  model  are  summarized  in  table  11  and  the 
results  predicted  by  the  Cocomo  model  are  depicted  in  table  12. 

The  Cocoao  model  computes  estimates  for  cost,  manpower,  and 
schedule  requirements  for  the  following  phases  of  software 
development  by  the  contractor  (only): 

o  Preliminary  design 

o  Detailed  design 

o  Code  and  unit  test 

o  Integration  and  test 

It  does  not  include  estimates  for  activities  such  as  requirements 
analysis,  formal  demonstrations,  and  project  administration. 

The  Cocomo  Model  predicts  that  JAMPS  software  development  in 
Ada  can  be  accomplished  In  12.9  to  16.4  months;  figure  5  indicates 
that  this  same  work  effort  (Tasks  15-19,  21-25,  31-32)  will  be 
accomplished  in  15  months. 

The  Cocomo  Model  predicts  that  software  development  will 
require  170  to  272  man  months,  depending  on  which  set  of  assumptions 
is  made.  These  predictions  correspond  with  151  mm  (optimistic)  and 
344  mm  (pessimistic)  estimates  computed  via  Method  1,  and  can  be 
compared  with  the  180  actual  man-months  expended  during  the  JAMPS 
implementation  in  "C". 

The  level  of  staffing  predicted  by  the  Cocomo  Model  (especially 
for  the  case  involving  pessimistic  assumptions)  indicates  that  a 
fairly  large  mainframe  computer  capable  of  supporting  as  many  as 
15  consoles  will  be  needed  for  Ada  software  development. 

The  costs  per  delivered  source  statement,  as  computed  by  Method 
1  and  2,  are  not  directly  comparable  because  the  Cocomo  Model 
does  not  consider  such  things  as  management  reserve,  contract 
monitoring  expenses,  etc.  The  cost  estimates  per  source  statement 
computed  by  Method  1,  $110.74  and  $179.46  for  the  optimistic  and 
pessimistic  cases,  are  less  than  the  ESD  average  ($200.00/source 
statement  );  this  is  to  be  expected  because  300  series 
procurement  regulations  are  assumed. 


Table  11 


Inputs  to  Cocomo  Model [15] 


Development  mode:  organic,  semidetached,  embedded 

Delivered  source  lines  of  code:  23,939  and  35,222  for  optimistic 

and  pessimistic  cases,  respectively 
Preliminary  design  costs:  $6200/mm 
Detailed  design  costs:  $6200/mm 
Code  and  unit  test  costs:  $6200 /mm 
Integration  and  test  costs:  $6200/mm 


Very  Extra 


Cost  Driver 

Low 

Low 

Nominal 

High 

High 

High 

RELY  required  software 

0.75 

0.88 

1.00 

1.15 

1.40 

reliability 

DATA  database  size 

0.94 

1.00 

1.08 

1.16 

CPLX  product  complexity 

0.70 

0.85 

1.00 

1.15 

1.30 

1.65 

TIME  execution  time 

1.00 

1.11 

1.30 

1.66 

constraint 

STOR  main  storage  constraint 

1.00 

1.06 

1.21 

1.56 

VIRT  virtual  machine 

0.87 

1.00 

1.15 

1.30 

volatility 

TURN  computer  turnaround  time 

0.87 

1.00 

1.07 

1.15 

ACAP  analyst  capability 

1.46 

1.19 

1.00 

0.86 

0.71 

AEXP  applications 

1.29 

1.13 

1.00 

0.91 

0.82 

experience 

PCAP  programmer  capability 

1.42 

1.17 

1.00 

0.86 

0.70 

VEXP  virtual  machine 

1.21 

1.10 

1.00 

o75o 

experience 

LEXP  programming  language 

1.14 

1.07 

1.00 

0.95 

experience 

MODP  use  of  modern 

1.24 

1.10 

1.00 

0.91 

0.82 

programming  practices 

TOOL  use  of  software  tools 

1.24 

1.10 

1.00 

0.91 

0.83 

SCED  required  development 

1.23 

1.08 

1.00 

1.04 

1.10 

schedule 

NOTE:  Underlines  are  used  to  indicate  the  inputs  selected. 
Numerical  values  are  cost  driver  multiplication  factors  used  in  the 
model. 
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Table  12 

Results  from  Cocomo  Model 
Optimistic  Case 


Schedule 


Phase 

Man-Months 

Cost  (K$) 

Months 

Staff 

Preliminary  Design 

20.1 

124.8 

3.0 

6.8 

Detailed  Design  (DD) 

33.5 

207.4 

5.2 

16.7 

Code  &  Unit  Test 

52.8 

322.2 

included 

in  DD 

Integration  &  Test 

64.1 

397.2 

4.8 

13.4 

170.4 

1,056.6 

12.9 

Productivity:  140.5  source  statements/mm 

Unit  Cost:  $44. 14/Delivered  Source  Statements 

Pessimistic  Case 


Preliminary  Design 

32.0 

198.4 

3.5 

9.1 

Detailed  Design  (DD) 

52.4 

325.1 

5.8 

23.2 

Code  &  Unit  Test 

81.7 

506.6 

Included 

in  DD 

Integration  &  Test 

106.0 

657.3 

5.7 

18.5 

Total 

272.2 

1,687.3 

15.0 

Productivity:  129.4  source  statements/mm 
Unit  Cost:  47.91/source  statement 
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The  nost  likely  cost  to  duplicate  JAMPS  software  in  Ada,  given 
the  constraints  provided  herein,  is  the  average  of  the  optimistic 
and  pessimistic  projections  computed  via  Method  1  (i.e.,  $4.5M). 
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SECTION  7 


ADVANTAGES  AND  DISADVANTAGES  OF  REIMPLEMENTING 
JAMPS  SOFTWARE  IN  ADA 


7.1  ADVANTAGES 

The  principal  benefits  of  undertaking  an  effort  to  recode  JAMPS 
software  in  Ada  are  the  following: 

o  The  use  of  Ada  will  promote  JAMPS  software  reusability  by 
lessening  the  cost  to  incorporate  JAMPS  programs  in  other 
systems. 

o  The  use  of  Ada  is  expected  to  decrease  JAMPS  life  cycle 
costs  because  of  improvements  in  software  maintainability. 

o  ESD  will  benefit  from  the  experience  of  an  acquisition 
program  Involving  the  use  of  Ada. 


7.2  DISADVANTAGES 

The  principal  disadvantages  in  recoding  in  Ada  are  as  follows: 

o  The  Air  Force  has  already  invested  20  man-years  in  the  JAMPS 
software  written  in  "C"  and  most  of  this  investment  will  be 
discarded  if  the  software  is  rewritten  in  Ada. 

o  Air  Force  program  offices  which  desire  to  use  JAMPS  software 
written  in  Ada  will  be  held  up  three  years  while  waiting  for 
the  Ada  programming  tools  to  mature  and  recoding  of  JAMPS 
software  in  Ada  to  take  place. 

o  There  are  risks  associated  with  using  Ada  at  this  time 

(e.g.,  programmer  productivity  with  Ada  is  unknown,  ESD  has 
no  experience  with  Ada  in  C3I  applications). 

o  In  the  short  run,  code  written  in  Ada  is  liable  to  be  less 
reliable  than  the  proven  "C”  software  in  JAMPS. 
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APPENDIX  A 


A  REPRESENTATIVE  EXAMPLE  OF  JAMPS  CODE  REWRITTEN  IN  ADA 


MITRE  personnel  at  the  Langley  site  selected  a  representative 
example  of  existing  JAMPS  code  to  be  rewritten  in  Ada.  This  example 
was  extracted  from  one  of  the  off-line  functions  and  is  depicted  in 
Attachment  1.  Its  purpose  is  to  convert  a  file  consisting  of  ASCII 
characters  and  numbers  into  a  file  consisting  of  ASCII  characters, 
binary  data,  and  an  index.  The  following  material  is  borrowed  from 
D.  J.  Criscione. 

During  the  conversion,  some  fundamental  choices  were  made  which 
affect  the  number  of  lines  of  Ada  source  code  produced.  Little 
regard  was  given  to  producing  code  which  takes  fullest  advantage  of 
the  features  offered  by  Ada.  Instead,  the  resultant  Ada  code 
closely  resembles  the  "C"  code  that  was  used  as  a  model.  Aside  from 
necessary  syntactic  changes,  only  a  few  small  sections  were 
redesigned  to  accommodate  language  constructs  which  differ  between 
"C”  and  Ada.  As  a  result,  the  lines  of  executable  code  remain 
roughly  the  same.  However,  the  total  number  of  lines  of  Ada  code  is 
much  larger  than  that  of  "C",  because  the  Ada  compiler  requires 
explicit  data  declarations  for  describing  the  information  contained 
In  records  (read  in  from  disk)  whereas  the  ”C”  compiler  does  not. 

The  ”C”  listing  sometimes  contains  several  local  variable 
declarations  in  a  single  line  where  Ada  encourages  the  definition  of 
a  single  data  declaration  per  line,  and  this  tends  to  distort  the 
results  shown  below: 


Category _ 

Program  Overhead 
Constants  used  by  the  compiler 
Specification  of  data  types  and 
data  structures 
Interface  to  UNIX  files  (code 
and  specification) 

Local  variable  declarations 
Executable  code 

TOTAL 

Brackets 

Continuation  Statements 
Complete  Source  Statements 


Lines  of  "C”  Lines  of  Ada 


5 

14 

49 

49 

23 

35 

3 

22 

7 

35 

134 

125 

1  ‘ 

231 

280 

-31 

-33 

-36 

167 

244 

Due  to  the  significant  number  of  missing  features  in  the 
Telesoft  compiler  used  in  this  experiment,  it  was  not  possible  to 
compile  (without  error  diagnostics)  the  280  lines  of  Ada  source  code 
referred  to  above.  As  a  consequence,  in  numerous  places,  Ada  code 
appears  as  comments  in  the  listing  wherever  it  failed  to  compile 
properly  (see  Attachment  2).  Circumventing  the  compiler  deficien¬ 
cies,  only  224  complete  Ada  source  statements  were  actually 
compiled,  resulting  in  5,566  bytes  of  object  code  or  24.8  bytes  per 
source  statement. 

Attachment  1:  Source  code  listing  for  "C”  code. 

Attachment  2:  Source  code  listing  for  Ada  code. 
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Attachment  1 


Representative  Example  Coded  In  "C” 
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♦♦♦  defines 

fff  Data  Base  pefines 

-  Q7/Q7SB3  */ 

« 

-.ef  mt 

naxmsgs 

ISO 

/* 

max 

messages  in  dir  */ 

z 

ef  me 

NAXKDSS 

600 

/* 

Max 

keyword  in  dir  */ 

s 

::ef  in# 

NAXDFIS 

1500 

/* 

Max 

dfis  in  dir  */ 

= 

:#f in# 

KDFIS 

SO 

/* 

Max 

dfi’s  in  a  kds  table  *' 

r 

::*f  in# 

NSTATES 

100 

✓  * 

Max 

states  per  line  (msg  tables)  */ 

- 

•  .ef  in# 

KSTATES 

100 

/* 

Max 

states  per  line  (kds  tables)  *x 

c 

..ef  in# 

DSTATES 

100 

/* 

Max 

states  per  line  (dfi  tables)  +/ 

= 

?ef  in# 

mstrha;; 

62 

/  + 

Max 

length  of  str  for  man  fids  e/ 

z 

•ef  in* 

MMANFLtiS 

3 

/  + 

Max 

mandatory  fields  in  a  msg  *xs 

.ef  in# 

SHRTLEN 

C. 

/* 

Max 

length  of  short  msg  name  »/ 

r. 

ef  in# 

LONGLEN 

20 

/* 

Max 

length  of  long  msg  name  *x 

= 

iff  me 

KDSLEN 

3 

/* 

max 

character  length  of  kds’s 

s 

ef  me 

FDFHLEN 

25 

✓  * 

Max 

character  length  of  fdfh’s  +' 

•ef  in# 

MAXUA- 1 

31 

/* 

Max 

characters  for  validation 

MED 

template  cod*  area 

r 

ef  i  n# 

dchaiui 

30 

/* 

Max 

E  types  for  a  single  chain 

;#t  in# 

otablc 

2C0 

/* 

Max 

entries  in  a  table  macro  */ 

ef  i nc 

DDUIS 

100 

/* 

Max 

duis  for  a  single  dfi  *' 

z 

ef  me 

dtabstr 

40 

/* 

Max 

characters  in  a  table  entry  */ 

- 

ef  in# 

KRSTATE 

SO 

/* 

Hax 

number  of  states  in  a  row  */ 

c 

•ef  in# 

MSGINDEX 

1 

- 

ef  m# 

KDS INDEX 

2 

ef  in# 

MSG 

3 

3 

(fin# 

KDS 

4 

3 

^ef  in# 

DFI 

5 

3 

ef  in# 

FDFH 

6 

- 

#f  in# 

INIT 

; 

/* 

initialize  data  tables  mode  */ 

ef  in# 

UPDATE 

3 

/* 

update  existing  data  tables  */ 

u 

.  ef in# 

DBGON 

1 

/* 

flag  */ 

3 

.ef  in# 

DDGOFF 

0 

✓  * 

flag 

s 

■ef  in# 

NFILEUfi 

:  4 

/* 

maximum  characters  in  file  name  »/ 

s 

:  ef in# 

TEMPFILE 

"ibld.tmp 

✓  * 

temporary  output  file  ex¬ 

e  »  i  n« 

strfile  • 

ibld.str 

/* 

temporary  table  string  file  */ 

3 

..ef  in# 

cun 

1 

i 

::* f  in# 

COMNOTaB 

2 

••#f  i  n# 

COMTAB 

3 

” 

:<ef  i  n# 

DIFNOThB 

4 

= 

■•ef  in* 

diftab 

? 

r 

ef  in# 

ALTCMN 

6 

s 

j#f in* 

DIF 

7 

3 

nef  in# 

C 

1 

r 

f  in# 

C 

2 

= 

3#f in# 

FIX 

1 

r 

..ef  in# 

UAR 

2 

7 

:.#f  i n# 

UNKNO-IN 

0 

/  + 

unknown  us»d  whan  trror  dettetad  +' 

- 

::ef  in# 

NA 

-1 

1 

J,2r  *7  f*  VF1 


■ve?  mxm\  *JT*T*  IrV*  V«TO^  V*  W  W 


,’  j| 
£fl 


>x| 

v| 

jSf 


truct  cod* 
c 

int  cdfitgpes 
int  cdfi) 
int  cdui) 
int  cranges 

float  cfhighs 
float  c  f  low; 
long  cl  highs 
long  c i lows 
int  c  m  i  n  s 
mt  ciiiiis 
int  clngths 
int  cents 
long  icnexts 


/*  1 :C  or  2:E  for  dfi  tgp*  */ 

/«  integer  dfi  nuaber  •' 
y*  integer  dui  nuaber  */ 

/*  I:,  integer  rang*/  Zifloating  point  range  *' 
y*  3:octal  range*  -lino  range  */ 
y*  value  of  upper  boundarg  (float)  +/ 

y »  value  of  lower  boundarg  (float)  *y 

y*  value  of  upper  boundarg  (long)  •y 

y *  value  of  lower  boundarg  (long)  *y 

y*  mmiaua  code  length  of  data  item  code*  *y 
y *  maxiaua  code  length  of  data  item  codes 
y «  length  in  bgtes  of  data  itea  codes  »/ 
y*  nuaber  of  codes  */ 
y*  location  of  next  dui  * y 


o  ndudt  <ttdio.h> 
snctude  <ctype.h> 

:  icludi  “di<intt“ 
r  -elude  ''helpstruet" 


•  f  me  • 

NENDF  I 

1 

/* 

ualuc 

returned 

froA. 

and 

defined 

in 

lookahead 

*/ 

a  -fine 

DU I NAME 

2 

/* 

ualue 

returned 

froA, 

and 

defined 

in 

lookahead 

*/ 

=  i-  f  me 

LIT 

3 

/* 

Ualuc 

returned 

f  roA. 

and 

def  ined 

in 

lookahead 

*/ 

r  f  me 

CODELINE 

4 

/• 

Ualue 

retui  ned 

f  roA. 

and 

in 

lookahead 

*✓ 

:  •  f  me 

RANGE 

5 

✓  * 

Ualue 

returned 

f  roA. 

and 

def  ined 

in 

lookahead 

*/ 

:  • fine 

OCT 

6 

/« 

ualue 

retui  ned 

f  roA. 

and 

def ined 

in 

lookahead 

•  / 

f  me 

FLOAT 

7 

/* 

ualue 

returned 

froa. 

and 

def ined 

in 

*/ 

:.-fme 

ENDFILE 

8 

/* 

ualue 

returned 

f  roA. 

and 

def  ined 

in 

look  ahead 

*/ 

=  i  -  f  me 

NAXLINE 

80 

/* 

MaxiAun  size  buffer 

for 

line  read 

*/ 

- ::  r  f  me 

INTEGER 

1 

/* 

Integer  range 

indicator 

a/ 

f  me 

FLTPT 

2 

/* 

Floating  Point 

r  *nge 

indicator  a/- 

a;-;  fine 

OCTRNGE 

3 

/* 

Octal 

range  indicator 

*/ 

r :.E  «pin.  apout. 

apreadout 

af open  t  ) : 

• ■ • uct  cod*  unde.  coderead.  apcode.  apcreadi 
■ -r  si inetMAXLINEl ,  sc  1 inetNAXLINEl .  sonecodeC  maxlinei ; 

9  leurpos-  Icurtap.  lcurlot.  Itmpoff.  ldfi.  ftell()i 
I  intent.  pus2.  siztmm.  lizttti! 

'  - • n ( ar  gc  > argv ) 

•'  ar  gc  I 
-  .r  aarguC  ] ; 


■nt  codtltn.  chk.  s.  loopl.  loops,  post; 
int  readchk  s  01 
char  cl 

char  «p I i nr •  apdfilme.  «pduilint.  apcline.  *pontcodt; 
char  *df i I ineCHAXLINEl.  sdu I  1 1 nr C MAXLINE] ; 


GRAND  OPENING  aaar 

if  large  <  3> 

< 

♦  pr  in r  t «  stdtrr ,  ■  tea  ERROR  aaa  an  input  and  output  file  must  ) : 
f pr  int f < stderr , ' pt  naatdNn" ■; 

•  x  it i  1  )  l 

) 

if  <(pin  .  f open! •♦♦argv. ”r "  )  i  : :  NULL) 

t 

fpr  inr  f  <  stdtrr  .  tea  ERROR  unable  to  open  Xs  for  rt adsn" .  aargv ) l 
tx 1 1 ( 1  II 

> 

if  <<pout  =  f open i **+argw. i >  : :  NULL) 

< 

fpr  intf  (stderr  .  ■»*«  ERROR  «««  unable  to  open  Xs  for  *r  item" . *argv») i 
ex  it ( I  >i 

> 


HWWUBMHiaW 


rv.v.v 


*.  ■•  W  V  V  -.  h.  1 


if  ((preadout  z  f ope n ( aargu.  “r  ••  t )  ss  NULL) 
f 

fpr  int.f  (stderr  .  "aaa  error  ***  unable  to  open  Xs  for  readsn" .  aargu) ; 
exitdis 

> 


'«»»  INITIALIZATION  CODE  mmmy 


pcode  z  tcodes 
pcread  :  tedder  e  ad : 


■*  Set  cur > or  locition  to  its  initial  position  after  the  index  */ 
leurloe  .  sizeof(long)  «  maxdfiss 


■•*  Set  the  positi:n  of  pout  (output  file  pointer)  •/ 
f  seek  (pout.  >  leur  toe  .  0) » 


»  Initialize  the  line  count  of  number  of  lines  read  ms 
linecnt  :  os 


/■«»*  BEGIN  PROCESSING  wear 

Z  • def  DEBUG 

fpr  mtf  <st  dout .  "►  ocess  mg  has  begun  <  *n"  ) ; 

=s--dif 

y*  Initialize  space  for  first  >"tad.  */ 
p l ine  :  cl >nei 

*  Get  tne  fust  :-.ne  of  tne  *  •  t  e .  This  loop  mill  process  the  DFI’s  my 
and  the  inner  loop  will  process  the  codes  for  each  DFI.  m/ 

while  (readchk  =  s  g* t * ( p  1  me .  m.  xlINE. p  i n )  > 

< 

if  (readchk  ::  EOF ) 
preof ( ) s 

*  Call  tne  initializing  routine.  *' 

in  it  i  al  ( >  s 

«  Initialize  tne  strings  that  are  being  used,  m/ 
pdf ii me  ;  sdf i  1 inei 
pduiime  z  sdui  lines 
ponecode  :  sonecodes 
pci ine  :  sclines 

•«  Find  whirre  the  input  file  pointer  is  positioned  and  increment  tne  m/ 

'•  line  count.  ar 

leurpos  z  fte))ipin)s 
♦♦I ineents 

*  Since  >«e  naue  a'.'eady  checveu  this  line,  we  know  we  are  working  with  m/ 
■*  a  new  Dft.  we  can  stai  t  extracting  the  information  that  we  want,  m/ 

if  (apline  ::  ’£*) 

pcode ->cdf i type  :  El 
else  if  (apline  :s  'C') 
pcode- >cdf i type  s  cs 

else 

< 

fpr mtf (s:aerr»'«aa  ERROR  earn  DFI  type  must  be  C  or  E.  "is 
fprintf (stderr*  '  l me  *o  n"» I  indent  > S 
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•  (  i  t  <  1 )  S 


> 

•'«  Convert  t he  DFI  nuaber  into  an  integer  by  substring  and  an  ascii  to  */ 
sm  integer  conversion.  my 

substr (p l ine.pdf i 1 ine. i.4) : 
sdf i I ineC4]  s  ’\0’t 

Before  we  do  the  conversion.  «e  must  replace  the  leading  blank  (if  my 
we  have  one)  aitn  zero.  my 
if  (sdfiimetoi  si  •  •) 
sdf  1 1  meCOi  s  'O'; 

pcode-icdfi  s  pato  i  (pdf i 1  me > i 

if  (pcode->cdfi  <  0) 

< 

fpt  mtf  i  stderr .  ••«**  error  **»  nonnuaeric  DFI  nuaber  xa". 
pcode-  >cdf  i ) ; 

fprintf (stderr."*  line  Xdsn". 1 ineent )» 

> 

if  (pcode->cdf i  >  MAXDFIS.' 

{ 

fpr mtf (st aerr. "**«  ERROR  mmm  DFI  nuaber  out  of  bounds  s  Hd". 
pcode- ;cdf  i ) ; 

fpr  mtf  (stderr.".  line  :<dm" .  1  intent); 

> 

'*  Convert  the  DUI  nuaber  into  an  integer  by  substring  and  an  ascii  to  my 
integer  conversion. 
substr (pi  me.edu 1 1 ine.5>3< ; 

Sdui I ineC3J  s  *vO'» 

pcode-cdui  s  patoi  (pdui  I  mt  is 

■  f  (pcode->cdji  <  0) 

fpr  mtf  ist  aerr .  •'«**  ERROR  «**  nonnuaeric  DUI  nuaber  fcd". 
pcode-  >cdui  >• 

fpr  mtf  (stderr.  ".  line  •'id'.n".  imeent)) 

> 

*  Multiply  the  Df;  nuaber  by  d  to  get  the  proper  offset  for  the  my 

*  index.  */ 

Idfi  :  4  *  (pcode— >cdf  i ) ; 

«  Clear  any  buffered  information,  *✓ 
ff lush (pout  >  > 
f f lush (preadout  >t 

preadout  s  pointer  to  output  file  used  for  reading,  my 

*  pout  i  pointer  »;  output  file  used  for  writing,  my 

»  Save  the  position  of  icurio:.  If  there  are  codes  or  a  range,  we  my 
«  will  want  to  erter  this  position  in  the  index  entry,  my 
leurtap  s  I  cur  loci 

•*  Seek  this  position  plus  the  size  of  the  structure.  */ 
f seek -pout >( 1c ur loc  ♦  s izeof ( opcode) ). 0) ) 
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wctb  BW:i J  r-  .•*»  TTygyry*  '■ 


'■*  Look  ahead  to  see  if  we  are  ready 
'*  on  the  value  returned.  *✓ 

while  <(loop2  r  lookahead(O) >  1  = 
< 

switch  (loopZ) 


to  process  the  codes.  Switch  •/ 
ENDFILE) 


< 

case  NEWDFI: 

Icurioc  s  ftell(pout): 
prstruc(Q)! 

/»  Return  to  outside  loop  +' 
Break:  r*  to  process  next  DFI.  */ 

case  DUINAME: 

*  When  the  DUI  name  is  continued  on  wore  than  one  line,  the  lookahead  *•' 
•*  routine  will  adjusts  the  file  pointer  and  increwents  the  line  count. 

-*  Continue  in  loop  looking  ahead.  */ 
break: 


case  LIT: 

A  LITERAL  nas  seen  found.  we  want  to  zero  out  any  values  that  may  *r 
-»  nave  hanged  before  discover  mg  the  LITERAL.  Me  search  for  the  •/ 

•«  next  r>Fi .  we  ire  then  prepared  to  look  ahead,  see  the  next  DFI.  •/ 

■*  and  then  we  will  write  the  structure  info  to  file.  *' 
initial*  >: 
searchC >: 
prstruc ( 1  l : 
break: 

case  codeline: 

•'*  Me  are  on  «  line  that  contains  codes  and  a  LITERAL  and  a  range 

has  not  been  fjjrd.  We  get  the  code,  check  to  see  if  it  is  continued  •/ 
■»  on  the  next  line  and  write  the  code  to  file, 
codelen  =  01 

posl  s  posz; 

pcline  =  getcode (p  1  inc  ) : 

While  fffenk  :  luokahe ad(0> >  ::  CODELINE)  ll 
(post  <  posZ)) 

< 

strmove (pc  1 1 ne.ponecode > : 
pcline  z  concat (ponecode ) : 

> 

+■»<  pcode->ccnt ) : 

When  the  first  :  ode  is  found,  set  the  minimum  and  maximum  codr  •' 
equal  to  the  length  of  that  code.  Otherwise  compare  the  size  of  the  •' 
*  code  t  .  see  if  exceeds  the  »ize  of  the  maximum  or  minimum  code  */ 

-*  length,  and  act  accordingly.  *' 

if  'PCOde->CCnt  : :  1) 

< 

pcode->cmm  =  s ize(pc  I  me > : 
peode-’emax  :  s i ze(pc I  ine ) : 

> 

else 

< 

if  ((sizf'iir.  :  s  i  ze  (pc  1 1  ne  >  >  <  pcode->cmm) 
pcodf->cmm  *  sizemin: 
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mssm 


> 


if 


((sizeniax  =  s  ize  <pc  1  in*  >  >  >  pcodr- >caax  > 
pcode->caax  :  sizeaax; 


codelen  s  sizeipcline)  +  it 
pcode->c Ingth  *-  codr  lent 


-  def  DEBUG 


3C  'id  i  f 


fprmtfistdout.  "Ismi"  ,  pc  line); 


-*  write  tiir  codr  to  thr  file.  *✓ 

for  itrfpc  I  inr>iizeof(chir)iCodrltn.pouU; 

Break; 

case  range: 

*  Wr  hiuE  found  a  left  parentheses  followed  by  a  non-alphabet  i  c  .  Me  are*' 
■»  ready  to  process  a  range.  *• 
r ange  (  ) : 
break: 

oef au  1 1  : 

f pr ;ntf < stderr  .  «**  ERROR  ***  Inapplicable  return'll 

fpr intf fstderr  .  •  value  =  *d"»  loopSi; 

fpr mtf (stderr.-.  line  kd^n". 1  ineent > ; 

e» 1 1 ( l )? 

break; 

> 

if  ( ( loop!  :r  NEHDEI 1  .  <100p2  ::  LIT)) 

break; 

> 

if  < I oop2  ::  EMDEILE ) 

< 

prstruc (0 • ; 
preof < ;; 

> 

>  ✓*  close  inner  loop  *' 

'*  end  prograa*/- 
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Attachment  2 


Representative  Example  Coded  in  Ada 
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This  package  iaplcaents  the  insert  “DEFINES*  used  by  the  C  implementation 
--  of  the  JAMPS  DFIDUI  parser. 

packade  DEFINES  is 

MAXMSGSt  constant  inteser  1*  150! 

MAXKDSS 1  constant  inteser  1  =  600i 
MAXDFIS1  constant  inteser  1  =  1500! 
kDFIS:  constant  inteser  1  =  SO! 

MSTATES1  constant  inteser  5=  1001 

KSTATES!  constant  inteser  1  =  1001 

DSTATES!  constant  inteser  1  =  100! 

MSTRHAXS  constant  inteser  5=  62! 

MMANFLDS!  constant  inteser  1  =  3! 

SHRTLEN1  constant  inteser  1=5! 

LONGLEN!  constant  inteser  1=20! 

KDSLEN1  constant  inteser  1=9! 

FDFHLEN1  constant  inteser  1=25! 

MAXUAL11  constant  inteser  1=35! 

DOMAINS:  constant  inteser  1=30! 

DTABLE1  constant  inteser  1=200! 

DDUIS1  constant  inteser  1=100! 

DTABSTR!  constant  inteser  1=40! 

KRSTATEi  constant  inteser  1=50! 

MSGINDEX1  constant  inteser  1=1! 

KDSINDEX1  constant  inteser  1=2! 


MSG  1 

constant 

inteser 

1=3! 

KDS1 

constant 

inteser 

1=4! 

DFI 1 

constant 

inteser 

1=5! 

FDFH1  constant  inteser  1=6! 

INIT1  constant  inteser  1=1! 

UPDATE!  constant  inteser  1=2! 

DBG0N1  constant  inteser  1=1! 

DBG0FF1  constant  inteser  1=0! 

MFILENM1  constant  inteser  1=14! 
TEHPFILE1  constant  strins  1  =  •  ibid .  tree  “ ! 
STRFILE 1  constant  strins  1 = “ ibid . str * ! 
CHN1  constant  inteser  1=1! 

C0MN0TAB1  constant  inteser  1=2! 

C0MTAB1  constant  inteser  1=3! 

DIFN0TAB1  constant  inteser  1=4! 

DIFTAB1  constant  inteser  1=5! 

ALTCHN1  constant  inteser  1=6! 

DIF!  constant  inteser  1=7! 

Cl  constant  inteser  1=1! 

El  constant  inteser  1=2! 

FIX!  constant  inteser  1=1! 

OAR  1  constant  inteser  1=2! 

UNKNOWN!  constant  inteser  1=0! 

NA1  constant  inteser  1=-1! 
end  DEFINES! 


with  text-iotdirect-iot JAHPS-STUBS i JAHPS. INPUT. JAMPS.OUTPUT t DEFINES! 
use  text_ioS 
use  integer_ioS 
use  definesS 

package  DFI.DUI. PARSER  is 

--  The  next  line  is  necessary  since  Ada  will  not  allow  the 
--  usale  of  undefined  twees  in  type  deffinition. 
twee  code? 

--  Soee  twee  deffinitions  to  be  used  in  the  structure  'CODE*, 
twee  access-code  is  access  code! 

--  NOTE!  Type  code  is  used  internalist  but  must  be  changed  into 
a  strea*  of  characters  via  unchecked  conversion  to 
accoaodate  the  character  oriented  C  imp 1 ementat ion . 
type  code  is 
record 

CDFITYPE!  integers  --  This  should  be  a  user  defined  type 

--  since  the  only  legitimate  values  are 

—  1  and  2. 

CDFi:  integers 

cnul :  integers  --  CDFI  and  CDUI  should  probably  be  user 

--  defined  typesi  but  I'm  not  sure  what 
--  ranges  would  be  legitimate. 

CRANGES  integer!  --  This  should  also  be  a  user  defined 

--  type  with  values  'inteser'r 
--  'floating-point'!  'octal't  and 

—  'no_range' . 

CFHIGH1  float! 

CFLOU!  floats 

CLHIGHi  floats 

CLLOU:  floats 

CHIN:  integer? 

CMAX!  integers 

CLNGTH i  integers 

CCNT!  integers 

LCNEXT:  accasj-codrS 

end  records 


--  Another  nori-iaeleaented  feature*  Record  representation  clauses 
--  are  not  yet  supported.  This  aeans  that  the  record  structure  here 
--  aay  not  aatch  the  eouivilant  C  structure* 

--for'  code  use 
--record  at  aod  B! 

WORD  !  constant  integer!=4)  --  Assuae  4  bytes  per  word* 


CDF  I  TYPE 

at 

0*U0RD 

range 

0  . 

.  31) 

CDF  I 

at 

14W0RD 

range 

0  . 

.  31) 

CDUI 

at 

2  *  W  0  R  D 

ranSe 

0  . 

.  31! 

CHANGE 

at 

34W0RD 

ranae 

0 

. .  3i ; 

CFHIGH 

at 

44 WORD 

rande 

0 

.  .  63! 

CFLOW 

at 

64W0RD 

ranse 

0 

.  .  63) 

CLHIGH 

at 

84UQRD 

range 

0 

.  .  63) 

CLLOU 

at 

lOtUORD 

range 

0 

.  .  03! 

CNIN 

at 

12*W0RD 

r  an  fie 

0 

.  .  32) 

CHAX 

at 

1 34 WORD 

range 

0 

.  .  32) 

CLNGTH 

at 

144U0RD 

range 

0 

.  .  32) 

CCNT 

at 

154U0RD 

range 

0 

..  32) 

LCNEXT 

at 

164U0RD 

range 

0 

.  .  03! 

. end  record) 

-  C  allows  unconstrained  strings*  Ada  does  not.  To  accoaodate  the 

-  existing  interface  a  large  string  will  be  used*  with  a  software  check 
for  the  deliaiter  used  by  C. 

procedure  NAIN(ARGC  i  integer!  --  nuaber  of  files 

ARGO  :  string)!  --  file  naaes 

type  WHICH-FILE-ERROR  is  (INPUT,  OUTPUT)! 

nd  DPI _DU I -PARSER) 


ackade  body  DF I -DU  I  ..PARSER  is 

procedure  HAIN ( ARGC  !  integer! 

ARGU  :  STRING)  is 

PIN  i  long_ integer !  --  SHOULD  BE  FILETYPE 

POUT  i  long-integer!  --  SHOULD  BE  FILETYPt 

PIN_hODE  :  constant  JAMPS. I NPUT . F I LE-MODE  !  =  JANPS- INPUT .IN-FILE! 
POUT-NODE  :  constant  JANPS. OUTPUT . F I LE-HODE  !  =  JANPS-OUT PUT . I N.OUT _F ILE 

file_being-Opened:  uhich.file-error; 

SLINE  «  JANPS-INPUT. INPUT-LINE) 

SCLINE  :  JANPS-INPUT. INPUT-LINE) 

S0NEC0DE  !  JANPS-INPUT. INPUT-LINE) 

PLINE  !  JANPS-INPUT. ACCESS- INPUT _L I NE ! 

PDF  IL  I NE  !  JANPS-INPUT.  ACCESS  -  I  NPUT..L  I  NE  ) 

PDUILINE  !  JANPS-INPUT. ACCESS-INPUT-LINE! 

PONECODE  !  string) 1  ..  80)! 

PCLINE  )  strinsd  ..  80)) 

STRING-END  :  integer) 

STRING-START:  integer) 

LINECNT  !  integer! 

PCODE  !  ACCESS-CODE! 

PCREAD  !  ACCESS- CODE! 

LDFI  !  long. l nt ege r )  --FILE-INDEX 

LCURPOS  !  long. i r.tese r !  --FILE-INDEX 

LCURTNF'  i  lons-inteser )  --FILE-INDEX 

LCURLOC  !  long-integer!  -FILE-INDEX 

LTNPOFF  !  long-integer)  --FILE-INDEX 


FTEL  !  lona_inteser i  --FILE-INDEX 

P0S2  i  integers 

F0S1  :  inteaer! 

CODELEN  !  inteaer! 

5 1  ZEN  I N  :  inteaer! 

SIZEMAX  !  inteaer! 

LOOP2  :  JAMPS-STUBS. LOOKAHEAD-VALUE! 

TEMP-LONG!  lond-inteder  i  used  in  inteaer  to  Iona  inteaer 

—  conversion. 

TEMP-INT  !  inteaer! 

OUTBUF  !  character! 

COUNT  !  inteaer! 

INPUT-INDEX  !  inteaer! 

--  a*******************  Start  of  Executable  Code  *************************** 

beam 

if  ARGC  <  3  then 

put- 1  me  C  *  ***  ERROR  *  *  i  an  input  and  output  file  Bust1)! 
pu t _ 1 i ne ( " be  naaed1)! 
return!  --  BAD-FILE-COUNT 
end  if! 

The  deliaiters  used  by  the  C  interface  for  unconstrained  strinas 
are  scanned  for  here.  Niaht  be  better  to  do  it  in  the  JAMPS-INPUT 
packaae . 

STRING-END! =1 i 
STRING_START!=li 

while  ARGV (STRING-END  ..  STRING-END+l >  /=  Vn*  loop 
STRING-END i«STRING_END+li 
end  loop! 

FILE-BEING-OPENED  !=  INPUT! 

JAMPS-INPUT. open (PIN. PIN-MODE. ARGVi STRING-START  . .  STRING-END) . • * ) 1 
STRING-END !=STRING_END+2! 

STRING-START! -STRING-END  I 

while  ARGV(STRING-END  ..  STRING-END+l)  /=  Vn*  loop 
STRING_END!-STRING_END+1! 
end  loop! 

FILE-BEING-OPENED  S-  OUTPUT! 

J AMPS -OUTPUT . open  <  POUT  » POUT -MODE  >  ARGV (STRING -ST ART  . .  STRING-END) . • • ) ! 

At  this  point,  the  C  code  executes  a  separate  OPEN  to  allow 
readins  froa  the  output  file.  This  does  not  seea  necessary 
since  the  Ada  DIRECT-IO  packaae  allows  a  file  to  be  opened 
for  both  readina  and  writind. 

***  INITIALIZATION  CODE  *** 

PCODE  !-  new  code! 

PCREAD!-  new  code! 

LCURLOC ! -UORDBMAXDF IS ! 

JAMPS-OUTPUT . set- i ndex  <  POUT . LCURLOC ) ! 

LINECNT  !=  0! 

PLINE  ! =  new  JAMPS- INPUT . I NPUT.L INE ! 


Get  the  first  line  of  the  file 


This  loop  will  process  the  DFI's 


MAIN-LOOP! 

loop 

--  UNIX  files  are  streaas  of  characters'  with  logical  records  deliaited 
--  by  a  single  deliaiter  character  specified  as  ‘/n*.  For  this  estiaate 
--  I  a*  assusing  that  the  iarleaentation  of  SEQUENTIAL.  10  will  return 
--  the  string  as  logical  records  with  the  */n‘  stripped  off.  The 
--  logic  which  assuaes  siaple  streaa  input  with  no  logical  record 
--  pre-processing  is  included  if  such  support  is  not  available, 
for  INPUT-INDEX  in  1  ..  SLINE'last  loop 
JAHPS- INPUT. read (PIN. INCHAR)  8 
exit  when  INCHAR  *  '/n'  ) 

SLINE< INPUT-INDEX  ..  INPUT-INDEX)  !  = 
unchecked-conversion! INCHAR) ! 
end  loop! 

J AMPS- INPUT . read (PIN' SLINE  > ) 

--  Check  for  terainating  condition!  End  of  input  file, 
if  J AMPS. INPUT .END-OF-FILE(PIN)  then 
JAMPS-STUBS. Proof ) 

put_line( ‘Exiting  procedure  MAIN-)' 
return)  --  NORMAL-TERMINATION) 
end  if) 

--  Call  the  initialization  routine 
JAMPS-STUBS. INITIAL) 

--  Initialize  the  strings  that  are  being  used. 

PDFILINE  !  =  new  JAMPS- INPUT . INPUT.L INE ) 

PDUILINE  • *  new  JAMPS- INPUT . INPUT-L INE ) 

P0NEC0DE  null) 

PCLINE  i  =  null) 

-  Set  the  index  and  increaent  the  line  count. 

LCURPOS  !»  JAMPS -INPUT • INDEX(PIN) ) 

LINECNT  S*  LINECNT  +  1) 

--  Start  extracting  the  inforaation  that  we  want, 
if  SLINE(1  ..  1)  =  ‘E*  then 
PCODE.CDFITYPE  !«  1) 
elsif  SLINE(1  .  .  1)  »  ‘C‘  ther. 

PCODE.CDFITYPE  !»  2) 
else 

put-line(*  ***  ERROR  ***  DFI  type  aust  be  C  or  E*>) 
put ( 1 inecnt  > ) 
return)  --  BAD-BF I -TYPE 
end  if) 

--  Convert  the  ASCII  DFI  nuaber  to  an  interSer. 

Note!  I  decided  to  handle  possible  blanks  right  here  since  that 
is  the  wav  it  was  done  in  the  C  code.  It  seeas  sore 
appropriate  to  handle  blanks  in  the  conversion  routine, 
if  SL INE ( 2  ..  2)  -  •  *  then 
SL INE( 2  ..  2)  !*  *0‘) 
end  if) 

pcode.cdfi  !-  JAMPS-STUBS. ASCI I-INTEGER! 

unchecked-convers ion( SL INE ( 2  ..  5))»4)* 

--  Check  for  valid  DFI  nuaber. 

if  pcode.cdfi  <  0  then 

put-lined  ***  ERROR  **<  nonnuaeric  DFI  nuaber*)) 
put (pcode .cdf i > ) 
rut-lined  line  nuaber’)! 
rut ( 1 inecnt ) ) 
end  if) 
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if  pcode.cdfi  >  HAXDFIS  then 

put.llmC  ttt  ERROR  ttt  DFI  nuabir  out  of  bounds  «'li 
put < acoda . cdf i ) I 
put_line(*  tins  nuaber*)f 
put ( 1 intent )  i 
•nd  iff 

--  Convert  the  DUI  nuabir. 

if  SL INE < 6  ..&)•=•'  than 
SLINE (6  ..  6)  *0*f 

and  iff 

pcoda.cdui  S«  JAHPS. STUBS. ASCI I-INTEGER( 

unchecked.conversionC SL INE ( 6  ..  9>)»4)> 

-  Check  for  valid  DFI  nuabar. 

if  pcoda.cdui  <  0  then 

put_line(*  ***  ERROR  tt*  nonnuaaric  DUI  nuabar'); 
put (pcoda.cdui > i 
put.line(*  line  nuabar* )« 
put ( 1 ineent >  ! 
and  iff 

--  Multiply  the  DFI  nuabar  by  4  to  tat  the  proper  offset  for  the  index, 
ldfi  !=  unchecked.conve rs i on ( 4  *  pcode.cdfi); 

—  At  this  pointt  the  C  coda  flushes  out  the  in  core  buffers.  There  is 
--  no  eouivilant  function  in  tha  DIRECT.IO  packaae. 

-  Sava  tha  currant  position  of  lcurloc. 

leurtap  i  =  lcurloc; 

--  Saak  to  this  position  in  the  output  file. 

JAMPS_OUTPUT. aet.index (POUT. lcurloc)  f 

--  Look  ahead  to  sea  if  we  are  readv  to  process  the  codes.  Switch  on 

—  tha  value  returned. 

L00P2 : « JAMPS.STUBS . LOOK AHEAD ( 0 >  f 
INNER-LOOP!  loop 
case  L00P2  is 

when  JAHPS -STUBS • ENDF ILE  => 

JAHPS -STUBS . erst rue (Off 
JAMPS.STUBS . preof  f 
exit  INNER-LOOP; 
when  JAMPS.STUBS. NEUDFI  «> 

LCURLOC i *  JAMPS-OUTPUT. INDEX(POUT) f 
JAMPS.STUBS. prstruc(O)  t 
whan  JAMPS.STUBS. DUINAME  =1 
null  f 

whan  JAMPS.STUBS. LIT 
JAMPS.STUBS. INITIAl  f 
JAMPS.STUBS. search; 

JAMPS.STUBS . PRSTRUC ( 1 ) f 


whan  JAMPS.STUBS. CODELINE  - 

codelen:-o; 

posi;«POS2t 

PCLINE ! “Unchecked- con vara ion( GETCODE (PL INE ) ) f 
white  JAMPS.STUBS. LOOKAHEAD(O)  *  JAHPS -STUBS . CODEL I NE 
and  P0S1  *  P0S2  loop 
PONECODE ! *PCL INE ! 

PCLINE! • JANPS. STUBS . CONCAT ( PONE CODE ) f 
end  loop! 

PCODE.CCNT!«PCODE.CCNT+i; 


^A 


if  PCODE.CCNT  •  1  than 
PCODE. CHIN? -PCLINE' last) 

PCODE .CHAXt "PCLINE' last) 
null; 
els* 

--  This  saction  had  to  ba  ra-writtan  to  accoaodata  tha  C  assianaent  stateaent 
--  within  tha  IF  stateaent. 

SIZEHINi-PCLINE' last) 

sizehaxs-sizehin; 

if  SIZEHIN  <  PCODE. CHIN  than 

pcode.chin?=*sizehin; 

end  if; 

if  SIZEHAX  >  PCODE. CHAX  than 
PCODE. CMAX  i=  SIZEHAX; 
end  if; 
end  if; 

CODELE N1 *PCL I NE ' last  U) 

PCODE. CLNGTH  ?»  CODELEN  til 
--  Urite  the  coda  to  the  file. 

for  COUNT  in  1  ..  CODELEN  loop 

OUTBUF i =unchecked_conversi onCPCLINE (COUNT  ..  COUNT)); 
JAHFS-OUTPUT .URITE(POUT.OUTBUF) 1 
end  loop; 

whan  JAHPS- STUBS. RANGEY  «> 

JAHPS. STUBS. RANGEX; 

--  Not  sura  if  these  lines  should  ba  counted.  Cor.siderina  the 
--  twee  checkins  on  L00P2»  the  others  case  should  never  occur, 
when  others  => 

rut-line?1  ***  ERROR  ***  Inapplicable  return?  value=*>; 

TEHP. INT ? -unchecked-conversion ( L00P2 ) ; 

Put; TEHP-XNT )  ;  , 

rut-line?1  line=*>) 
put< linecnt) > 

end  easel 

--  At  this  Point  the  C  listinH  checks  eSain  for  LOOPZ  »  NEUDFI  or  LIT 
--  The  lines  are  not  included  here  (redundant)  and  should  also  be 
--  excluded  froa  the  count  of  lines  in  the  C  listina. 

L00P2  ? « JAHPS -STUBS . LOOKAHEAD?  0 ) 1 
end  loop  INNER. LOOP; 
end  loop  HAIN.L00P1 

HANDLE  EXCEPTIONS 

exception 

when  NAHE-ERROR  i  USE-ERROR  -> 

if  FILE-BEING-OPENED  “  INPUT  then 

put-line? ’***  ERROR  ***  unable  to  open  '  t  ARBV (STRING. ST ART  .. 

STRING-END)  t  •  for  read’)? 
return)  --  BAD-INPUT-FILE 
elsif  FILE. BEING-OPENED  »  OUTPUT  then 

put.line( ****  ERROR  «*t  unable  to  oeen  '  X  ARGV (STRING. ST ART  .. 

STRING-END)  t  ■  for  write1 >t 
return)  --  BAD-OUTPUT. FIlE 
and  if) 

end) 

end  DF I _DU I -PARSER) 
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